Slack導入で気をつけるべきセキュリティのポイントとは?
会社での連絡ツールやコミュニケーションツールといえば、電話やOutlookなどのメーラー、グループウェアです。
ここ数年で社員間のコミュニケーションの活性化のため、Slackに代表されるチャットツールが注目されています。
「でも、チャットツールは使いたいけど、セキュリティ面が不安だなぁ」
と思われている情シスの方もいらっしゃると思います。
そこで今回はチャットツール導入で気をつけるべきセキュリティについて、世界的にも使われているSlackをベースにいくつかのポイントでご説明します。
なかでも重要なポイントは、”コミュニケーションの定義”と”機密情報の定義”です。
目次[非表示]
- 1.今までのコミュニケーションツールとの違い
- 2.情シスが導入で気をつけるべき点
- 2.1.使用目的
- 2.2.コミュニケーションの範囲
- 2.3.テレワークを想定
- 2.4.私用スマホへのアプリインストール
- 2.5.社内システムとの連携
- 3.情報の機密レベルを定義する
- 4.まとめ
今までのコミュニケーションツールとの違い
まずは今までのコミュニケーションツールとSlackの違いを整理します。
主な違いは、以下の3点です。
- クラウドであること
- ビジネスではメーラーとの併用が必須であること
- 話題やプロジェクトごとに参加メンバーを決められること
クラウドであること
Notesに代表されるオンプレミス型のグループウェアとは違い、クラウド環境で提供されるサービスです。
Slackは外出先でメッセージの確認やテレワークでの連絡のやり取りなどで活用が期待できますが、一方で情報がインターネットという“社外”に出るので、社内で情報が完結していた環境とは違ったセキュリティを考える必要があります。
また、クラウドサーバであってもハウジングのような自社専用サーバを設けることはできないため、共有サーバーであることを前提に使用することになります。
会社によっては、共有サーバーはセキュリティポリシー上、NGという場合があるのではないでしょうか。(ちなみにSlackのサーバーは日本国内にもあるようです)
ビジネスではメーラーとの併用が必須であること
「Slackを導入すればメーラーは必要なくなる」と思いがちですが、実はそうではありません。
取引先をはじめとした社外への連絡は今までどおりOutlookやGmailに代表されるメーラーおよびメールサーバー設置が必須になります。
よくSlackは「さまざまなシステムと連携ができる」と言われるため、メーラーとも連携でき、Slack一本で運用できそうに思えますが、違います。
たとえばMicrosoft系でいうとMicrosoft 365のみ、しかもメーラーとしてのOutlookではなく、カレンダーやOne Driveなどとの限定的な連携となるため、現実的にはメーラーとの併用が必須です。
話題やプロジェクトごとに参加メンバーを決められること
LINEをイメージしてもらうとわかりやすいかと思います。個別チャットのほか、グループを作って特定の仲間同士でチャットする、ということがSlackでもできます。
新サービス開発や社内デジタル化といったプロジェクトごとにチャンネルを作ることで、関係している社員のみで情報交換することができるため、他のメールと混合することがなくなり、かつ後から過去のチャットを見返すのが容易になります。
また、会話に近いやりとりになるので、些細なことでも意見を言い合え、宛名や定型文、署名を入れて送信してしまいがちなEメールとは、スピードややり取りする情報量に大きな差が生まれます。
とくにSlackは他のチャットツールに比べて、機能や拡張性、UI、制限などで優れているため
自社仕様にすることで使いやすさが格段に上がります。
情シスが導入で気をつけるべき点
Slack導入の主な目的は、コミュニケーションを円滑にすることです。
逆に言うと、導入できたとしても、円滑なコミュニケーションが実現できなければ意味がないとも言えます。
情シス担当としては情報漏洩等のリスクを気にして最大限の制限をかけたくなりますが、
円滑なコミュニケーションが実現するためのSlack導入に向けて、以下の5つの視点で気をつけるべき点を整理します。
- 使用目的
- コミュニケーションの範囲
- テレワークを想定
- 私用スマホへのアプリインストール
- 社内システムとの連携
使用目的
コミュニケーションと一言でいっても、誰とどんなやり取りをするか、具体的な使用目的を整理する必要があります。
たとえば、部内の連絡用であったり、部門をまたいだプロジェクトメンバー同士の情報共有であったり、さらに社外のパートナー企業との連絡用、社内のヘルプデスク窓口、各種申請ワークフローなどの用途が挙げられます。
緩い使用目的で導入すると、いつの間にか誰も使わなくなり、管理コストだけがかかり続けてしまいますし、最悪、誰も管理していないSlackがセキュリティホール(※1)になってしまう恐れもあります。
後から導入効果の検証をする、という点でも使用目的を明確にしておきましょう。
※1 セキュリティホール:セキュリティ観点で脆弱性があり、攻撃者から狙われやすい抜け穴のこと。
コミュニケーションの範囲
使用目的において、自社内だけで使用するのか、社外の人ともやり取りするのかなど範囲の整理も重要です。
なぜなら使用する範囲は、万が一情報漏洩した場合の影響範囲に関係するからです。
Slackは気軽にコミュニケーションできるかわりに、いわゆる“誤爆”が頻発する可能性があります。
複数のチャンネルで同時にチャットをしていると、チャンネルやスレッドを間違えることがあります(投稿したコメントを削除したり編集したりできますが、誤爆することには変わりありません)
もちろんEメールでも誤送信がありますが、宛先やCCにいるメンバーが見えるので、送信前の確認や、ディレイ送信(※2)の設定で確率を下げることができます
万が一、社外の人に機密情報を“誤爆”してしまったら大問題になってしまいます。
情シスとしては、社内、社外、併用とSlackでのコミュニケーションの範囲をどこまでを許可するのか整理します。
また情報漏洩した場合の影響範囲と、リスク対策も考えておく必要があります。
ちなみに、自社社員は社外の人を招待できないような制限をかけていても、招待されれば
社外のワークスペースに参加できる、ということがあります。
情シスが気づかないうちに社員が社外とSlackでつながっているケースがあるので注意しましょう。
※2 ディレイ送信:遅延送信。送信ボタンを投下したあと、数秒から数分経過してからメールを送信するようにできる技術や仕組みのこと。
テレワークを想定
テレワークやレンタルオフィスといったオフィス以外での仕事も増えています。
Slackは、まずは社内使用を想定しての導入が一般的です。
今まではオフィスに全員が出社していたので問題になりませんでしたが、テレワークが進む昨今、社員の自宅や外出先での利用も想定する必要があります。
セキュリティを確保しつつ、社員の使いやすい環境をどう構築するかが重要です。
たとえば、
- IP制限をかけたり、デバイス認証した会社貸与のPCからしかアクセスできないようにする。
- 私用PCを使わせるならば、Splashtopに代表されるリモートデスクトップのインストールやアンチウイルスソフトのインストール、会社が決めたプロバイダーに加入させる。
といった、Slackの利便性を損なわせない方法があります。
私用スマホへのアプリインストール
セキュリティの制限を何もかけないと私用PCやスマホなどの端末にSlackアプリをインストールし、Slackにログインができてしまいます。
(二重認証の設定で回避可能ですが、社員自身のアドレスに認証を飛ばしていれば簡単にログインできてしまいます)
ログインできる私用PCがウイルスにかかって情報が漏洩してしまった、スマホを紛失して中身を見られてしまった、なんてことが後からわかって対応するのではなく、しっかり対応する必要があります。
貸与端末にだけ制限をかけて、私用端末の対応が抜けていたなんてことはよくあることです。
社員を信じて日々の運用を任せたいところですが、情シス担当としてはリスクヘッジのため、アプリをインストールできたとしても会社が用意した環境以外はログインできないようにする設定をするように対応しましょう。
社内システムとの連携
社内で使用している各種システムと連携させるか、Slack単独で使用するか整理します。
Slackは基本チャットツールのみの機能なので、使用用途によっては、機能にないカレンダーやメーラー、タスクやプロジェクト管理ツールと連携させることで使い勝手が大きく向上します。
開発コストはかかるもののオンプレミスの社内システムとも連携させることは可能です。
Slackでやり取りしている当初の情報レベルは低かったが、他システムと連携することにより重要度の高い情報が図らずも社外のネットワークとつながってしまい、漏洩リスクが高まってしまうこともあります。
以上、Slackを導入する際、主に気をつけるべき点として5つ挙げました。
すべての点で共通して言えるのは利便性を損なわずセキュリティをどう担保するかのバランスを情報システム部がしっかり設計できるかです。
情報の機密レベルを定義する
上記してきた通り、一口にセキュリティと言っても、どう整理していくか難しいところです。
基本的には「情報の機密レベル」の視点を持つことです。
Slackでやり取りされる情報は、すでに世に公表されている情報なのか、従業員の日頃の会話なのか、社外機密である商品開発情報なのか、顧客の個人情報なのか、社内でも他部署には知られてはいけない情報なのか、機密レベルの合わせてきちんと整理します。
きちんと整理できていないと、極端な話、会社概要といった公表されている情報と未発表の新サービス情報が、同じレベルの情報として取り扱われてしまい、Slackを導入して良いものなのか否かの判断すらできなくなってしまいます。
情報の機密レベルは、漏洩した際の影響の大きさでランク付けをします。
情シス担当は、Slackの中でやり取りされる情報を事前に定義された機密レベルと比較し、適切なITインフラ環境を整えましょう。
まとめ
Slackはクラウドツールのため、情報が必ずインターネットという“社外”に出て、かつ社外のサーバで情報が保管されます。
業種の特性やセキュリティポリシーによっては、クラウドサービスはどこに物理サーバーがあるのか、セキュリティ管理がどうなっているかを気にする企業もあります。
当然、個人情報保護法やGDPR(※1)も鑑みたセキュリティ評価をすべきなのですが、気持ち的に情報は社内のサーバで管理すべきだと考えたくなります。
一方で、昨今では社内にあるから安全とも言えず、逆にクラウドサーバーの方が安全とも言われていることも理解しておきましょう。
情シス担当としては、どうしても情報漏洩などのリスクを考えるとネガティブになり、あえてリスクのあるツールを入れる必要がない、自らの仕事を増やす必要がない、と考えてしまうかもしれません。
本来、情報システム部門は会社のセキュリティを守るという役割のほか、情報やデータ活用を促進するIT環境の構築という役割もあります。
後ろ向きには考えず、導入するならどうしたらよいかを考えます。
そういった点で、Slack導入で、社員がどう使うか、それによってどんなリスクが発生する可能性があるか、リスクを未然に防ぐ方法は何なのか、万が一リスクが発生したらどう対応するかを会社のITインフラを支えるプロとしてバランス感覚を持って対応していくことが重要です。
※1 GDPR(General Data Protection Regulation):EU域内の個人データ保護規定
※この記事は、公開時点の情報をもとに作成しています。