[Slack Frontiers Tourレポート] Slackにおけるセキュリティの取り組み

オペレーション部　江口です。

2019年9月17日に開催されたSlack主催のカンファレンス、「Frontiers Tour Tokyo」のレポートです。

この記事ではその中のセッションで、Slackにおけるセキュリティの取り組みについて説明した「エンタープライズ企業に求められるアジリティーとセキュリティ」についてまとめます。

セッションの内容としてはセキュリティに厳しいエンタープライズ企業において、Slackを利用して社内のビジネスのアジリティを高めつつセキュリティを保つ、ということがテーマで、以下のようなことが行われました。

• Slack自体のセキュリティの取り組みの紹介
• ユーザに提供されているセキュリティ確保のための機能の紹介
• 実際に厳しいセキュリティ基準を全社で敷いているユーザ（NTTデータ）を交えたQAセッション

Frontier Japanでは全体として「Slackはメールに優る」ということを強調していましたが、一方ではビジネスにおいてすでに長く使われているメールに比べて、Slackのセキュリティ対策を心配する企業も多く、それに対しての説明と言えるセッションでした。

セッションの内容

はじめに

【登壇者】Slack Japan エンタープライズセールスマネージャ 熊谷 喜直氏

• Slackを導入することによりアジリティ、すなわちスピーディでオープンなコラボレーションが実現できる
• 一方で、エンタープライズ企業はSlack利用におけるセキュリティについて不安の声が聞かれる
  • Slackのクラウド環境はセキュリティ面で大丈夫なのか？
  • 機密性の高い情報が漏れたら?
  • 社員がモバイルデバイスを失くした時は？
• Slackとしてのメッセージは「ご安心ください」
  • Slackはすでに高いセキュリティ基準を必要とする企業で採用されている。例えばイギリス司法省、NASAなどでも利用されている
• 実際のところSlackではメールよりもセキュリティが強化される

詳細はSlack最高セキュリティ責任者ラーキン・ライダー氏より説明する、ということで氏が紹介されました。

slackのセキュリティへの取り組み

【登壇者】Slack最高セキュリティ責任者 ラーキン・ライダー氏

Slackのセキュリティプログラムは、以下の4つで構成されている。

• コンプライアンス&認証
• ID管理
• 監査
• アクセス制御

コンプライアンス&認証

• Slackは以下のような認証を取得している。

2016 SOC2 CSA(Star Level 1) 2017 HIPAA, ISO27001, FINRA 2018 ISO 27017,27018 NIST 800-171, GDPR, FedRAMP, G-Cloud(UK Gov) 2019 SOC2+HITRUST, FedRAMP Moderate

またSlack上にアップロードしたデータをどこに配置するか、データ所在地(Data Residency)を指定できる機能を追加。 2020 1Qに日本対応予定。

注) Slackの取得認証については下記URLでも確認できます。

https://slack.com/intl/ja-jp/security

ID管理

• 多要素認証に対応(SMS、認証アプリ)
• IdP(Identity Provider)連携対応

監査

• eDiscovery対応(電子証拠開示)対応 (Slackでやりとりしたメッセージ・ファイルを全て書き出して保存する)
• DLP(Data Loss Prevention/データ損失防止)対応 (センシティブな情報が共有されることを防ぐ)

DLPのデモとして、顧客のID情報がSlackのチャンネルに書き込まれた際に自動的に隠される（各ユーザーから見えなくなる）という機能が紹介されました。

参考URL: Slack の Discovery API ガイド

アクセス制御

• Enterprise Key Management(EKM): Slack内の会話やファイルなどの各データをAWS KMSで管理される独自の暗号鍵でユーザが管理。AWS上で鍵のアクセス権を設定することで、ユーザがどのデータにアクセスできるかを細かく制御可能
• セッション管理：ユーザのリモートセッションを切断できる。特定のデバイスのセッションの切断が可能とのこと

参考URL: Slack Enterprise Key Management

デモでは、EKMのデモとして実際にAWS上で鍵のポリシーを編集してあるチャンネルへのアクセスを制限する・セッション管理のデモとして、アカウントを乗っ取られたと思われる（通常とは異なる場所からアクセスしている）ユーザのセッションを切断する、という機能が紹介されました。

ユーザとのQAセッション

【登壇者】 - Slack最高セキュリティ責任者 ラーキン・ライダー氏 - NTTデータ　デジタルビジネスソリューション事業部 部長 齋藤 洋氏

一通りSlackのセキュリティについての取り組みについての紹介を終えたところで、実際に高いセキュリティで運用しているユーザとしてNTTデータ齋藤氏が登壇しました。

NTTデータSlack導入の背景

• NTTデータはかなりセキュリティ・コンプライアンスに厳しい
• 一言で言うとプロキシが開いていない。そのため、社員はSlackやBoxのWebサイトにすらアクセスできない
• しかし、Workstyle as as Serviceというサービスを展開するにあたり、SlackやBoxの利用が避けられない状況となった
• このセッションでは詳しくは触れないが、セキュリティの基準を下げずにSlackやBoxの利用を実現している

以後はライダー氏と齋藤氏の間のQAセッションとなりました。

※以後、Qは齋藤氏、Aはライダー氏

Q（齋藤氏）:

• 今まで（NW的に）閉じ込められていた社員が他の会社の社員ともコミュニケーションが取れる。社員はコミュニケーションを撮りたがるが、社員の機密情報の投稿は抑えなければいけない。どう抑えるべきか、そのバランスは

A（ライダー氏）:

• Slackにとってもこの問題はチャレンジの一つである。
• どの情報がセンシティブなものか、社員は自分で考えたくはない
• まずは社員を教育して、パブリックチャンネル、プライベートチャンネルの使い分け（どんな場合にプライベートチャンネルを使うべきか）を知ってもらうこと
• もちろん、紹介したDLP機能を利用して特定のデータを削除するのも良い
• どのような情報を共有すべきか否か、Eメールに関してはすでにルールがあるはず。それをSlackに援用してもよいのでは

Q（齋藤氏）:

• 日本の企業の多くはEメールはすでにさまざまな対策が施されていて安全という認識。SlackがEメールより安全と主張するのはなぜ？

A（ライダー氏）:

• Eメールは扉を閉められない家のようなもの。誰でも入ってくる（＝メールを送る）ことができる
• 攻撃者はメールを送る方法を模索し、フィッシングサイトに誘導したりマルウェアに感染させようと常に狙っている
• Slackでも外部とのコミュニケーションは共有チャンネルで行うことができ、そのほうが安全
• また、Eメールでは送ったデータはもはや自分のコントロールを離れ、転送などで誰の手に渡ったかなどを把握することはできない
• Slackであれば、APIやツールを用いて、Slack上で共有したファイルを誰がダウンロードしたかなどを把握することができる

その他、「先行してDLPを導入している企業からどういうフィードバックがあるか」「今後どういったコンプライアンス面でのエンハンスを考えているか」といったQAがありました。

まとめ

再び熊谷氏が登壇。 冒頭で掲げた下記の懸念について、以下のようにまとめました。

• Slackのクラウド環境はセキュリティ面で大丈夫なのか？　→　数々の認証を取得して堅牢な運用を行なっている。多要素認証やSSO連携などでなりすましログインができないID管理を提供している
• 機密性の高い情報が漏れたら？ → DLPやeDiscoveryとの連携を提供。また、万一情報が露出してしまった場合でも、EKMによりユーザ自身で情報の公開を制御できる
• 社員がモバイルデバイスを失くした時は？　→　セッション管理によって管理者が特定のデバイスからのアクセスを無効にできる

Slackのセキュリティの取り組みについて、よくまとまったセッションだと思いました。Slackの導入についてセキュリティ面で懸念されている方の参考になればと思います。