シンジです。個人での利用、会社での利用に問わず、クラウドサービスに登録した自分の情報や普段利用するデータ、誰にも教えたくない秘密情報であったとしても、利用者本人のみが利用できる保護されたものだと思っている人も多いようですが、そんなわけあるか。
クラウドサービスのデータの所有権
所有権とか言い出すと、どの国の法律でどう定義されているから云々みたいな話になります。権利だけで挙げても、著作権や使用権、再利用権など広がる広がる。所有権だけを見て国内民法で見てみると、データは無体物であって民法上の所有権の対象にはならないとか言われる始末なので、いやいやそんなこと言われましても俺のものは俺のものですとか言いたくなるかもしれません。
全部が全部そうなってるとは言いませんが、どんな大手の有名クラウドサービスであろうが多くの場合、「クラウドサービスに上げたデータは、クラウド事業者のもの」です。
Googleのサービスがどんどん便利になるのも、利用者が利用前の許諾しますねボタンで許諾しますってポチーしてるからなんですね。個人利用は個人で考えてくれってことなんですが、会社や組織でクラウドサービスを利用する場合、これどうしたらいいんでしたっけ。
クラウド事業者も対応策を出してます
IaaSやPaaSの色が強いAWSの場合、クラウドに上げたデータ、全部AWSの持ち物なんでよろしくとかいう話でAWSのビジネス拡大ができるわけがないので、サービスごとにどの様に設計され、どんな提供があるのか明記されてたりしますが、Microsoftしかり、このクラスの会社と同様のセキュリティ、運用体制でサービス提供ができる組織がごろごろ存在するわけがないですね。
特に今回はカジュアルに利用されるSaaS
SaaSの場合は利用もカジュアルなんですが、サービス提供、つまり会社がしれっと出来上がって営業するのもカジュアルなので、まぁ結構データ保護は適当です。
事業者がユーザー領域に一切アクセスできないと困る事
BoxやZendeskなどのクラウドサービスは、サポートの品質を高める為に、利用者（テナントの管理者）が任意で一時的に事業者に操作権限を与えることが出来る仕組みがあります。利用中にトラブルが起きたとき、サポートに連絡しますが、どこがどうなってるというのを確認する為に、利用者からの許可が行われない限りは確認を行う事ができない仕組みが採用されています。
クラウドサービスを利用してサポートに設定等で助けて連絡をしたとき、このような許可操作なく事業者側が「ここ間違ってたよ」とか「この設定入れといたよ」とか、ありがと〜たすかる〜で終わると思いますが、これはつまり事業者側が利用者の許可無く操作できることの裏返しです。
クラウド事業者が利用者に確認なくデータを利用するのはよくあること
許諾無く、となると問題ですが、利用前にポチーしているので、許諾はしていると。とはいえ、勝手に自分データが事業者に好き放題使われるかと思うと、なんかもやっとしますよね。個人なら「嫌なら使うな」で終わりますが、会社で使うとなると話は変わってきます。
例えばSUICA
決済に便利で使ってる人も多いと思います。電車どころか買い物も出来ちゃう。この利用データはJR東日本が所有しており、マーケティングなどへの活用の為に他社へデータを販売しています。
同じように、クラウドサービスに登録されている全てのデータは、何かしらのために利用されます。それが、サービス事業者の自社サービスの品質向上なのか、あいつの秘密知ってるぞふっへっへなのかまできっちり追いかけることは出来ませんが、特に大きな会社で採用される有名クラウドサービスについては、国に関わる機関からの要請でデータ提供することもあります。
どれも基本的には「悪用」ではないのですが、漠然とした不安を抱えるクラウド怖い病になる人もいるかもしれません。しかしよく考えてほしい。サービス提供事業者の会社が訴訟され多額の賠償金を抱えるようなデータ利用を行う事にメリットは全くないし、そのデータそのものに価値など無い。
情報の取り扱いで命に関わる組織
つまり軍だとか、FBIやCIAですね。このクラスと同程度のセキュリティ実装、同程度のセキュリティ運用を行う一般の営利組織があったら、コストも手間もやばすぎて即潰れそうです。が、そういったところがどの様に考えどのように実装しているのかを知ることは参考になるわけです。公開されているわけもないんですが。俺はそこまでやらなくてもいいよなってな言い訳です。言い訳にも根拠が必要。
この辺をネタに深掘りすると話題がそれるので本題へ。
あるとき元CIAのCISO（セキュリティの一番偉い人）と一緒に飯を食うことがあったのですが、その時の話題でつまるところ結論は、
「SaaS使うなら証明書は自組織のものにしよう」
ってことです。
SaaSのデータの暗号化する鍵を自分の鍵でやる
自社のデータを自社の保有物として自社で管理していることを証明するためには、この方法がベストです。北米企業だとこの仕組みを利用するユーザー企業は結構多いのですが、日本企業だとまだまだ知られてすらいない印象です。
データを保護する上で、どの鍵を使って暗号化して、どの鍵で復号化して、鍵はどの様に管理されているのかを追跡できる状態にしておくことは重要です。
SaaSの暗号化鍵を自社で管理することの意味そのものについては、BoxとSlackの説明が分かりやすいのでどうぞ。
Box Keysafe
https://www.box.com/ja-jp/security/keysafe
Slack EKM
https://slack.com/intl/ja-jp/enterprise-key-management
Slackの暗号化鍵を自社管理する
今回はSlackにフォーカスして紹介します。通常Slackは、Slackが利用するMySQLにデータが記録されていますが、ここでMySQLの機能を使って暗号化処理を行っています。この鍵を自社管理にするために、Slack EKM（エンタープライズ・キー・マネジメント）というサービスに申し込んで、手続きを進めます。
暗号化の仕組みが変わる
暗号化鍵は、利用者のAWSアカウントで、Amazon KMSを利用して鍵管理を行います。Slackに投稿されたメッセージなどは、いったんSlack EKM Serviceに入り、顧客のKMSから鍵を取得して暗号化します。鍵は利用者のAWSのCloudWatchに、5分間キャッシュされます。
鍵のスコープを毎回確認するため（Revokeの確認をしたりする）、毎回毎回確認するような仕組みになっています。これらは全てAWSのCloudWatchやCloudTrailにログとして残ります。
鍵の利用で以前より複雑な経路と処理になるので、レイテンシーの発生を懸念します。メッセージ送ったのに届かないとかになったら辛すぎです。基本的にはキャッシュがあるため、レスポンスの悪化は最低限になっており、EKMとAmazon KMSを、同じリージョンに置くようにしているため、最大限の配慮がなされており、実際に遅延を感じることはありません。
AWSのCloudWatchには、暗号化・復号化、Scopeに関するログが残ります。EKMがキャッシュされた鍵を使った場合は、その情報は書き込まれません。鍵のキャッシュについて設定の変更はできません。AWSのCloudWatchには、Slackで投稿したメッセージなどのそのものが入ることはありません。
Slackの鍵から自社の鍵に変更する、または自社鍵管理を辞める
EKMの利用を開始すると、Slackに投稿されている全てのデータの暗号化処理が始まります。過去のデータも含めて全てです。この時、利用者への制約や負担は一切無く、ただ待つだけです。もしEKMを辞めたいと考え、元のSlackの鍵に戻すとなっても同様です。
暗号化の完了までに、シンジのワークスペースで24時間ほどかかりましたが、予想では多くの企業が土日で終わる程度、どんなに巨大でも1週間も見れば終わるのではくらいの速度感です。
99%からが長いのはご愛敬です
EKMは複数の鍵を利用し、スコープの指定ができる
ここまで細かい制御ができるのはSlackだけなのではないかと思うのですが、EKMでは複数の鍵を同時に使うことができるため、どの情報資産になんの鍵をどのように使うか制御できます。大きいファイルや複数行のメッセージを投稿した時に、暗号化のパフォーマンスを上げるため並列処理を行いますが、ここで複数の鍵を使います。
鍵のアクセスコントロールは、Amazon KMSのPolicyをそのまま利用できます。
スコープは、messageなのかfileなのかってな具合です。更に、対象のオーガナイゼーション、ワークスペース、チャンネル単位などで制御できます。もしインシデント発生時にSlack全部止まるとつらぽよな時に、対象のチャンネルだけを復号化禁止にするなどを想定しているらしいです。
AWSのアカウントが必須
Amazon KMSを利用するので、AWSアカウントが必要です。ただ、AWSの知識が必要ということはなく、指示通りにポチポチするだけです。
流れはこんな感じです
- us-east-1を使う
- KMSでマスターキーを設定し、SlackにARNを渡す
- マスターキーのPolicyを設定する
- CloudTrailを設定する
- CloudWatch Logsを設定し、SlackにLogGroupのARNを渡す
一部の復号化を禁止したりして遊びます
こんな風に出るんですね〜
Sandboxで遊んでるときのスクショです
進捗はbotが教えてくれる
さすがSlackですわ。オーナーにだけ通知が来ます。
bot便利だなぁ〜
ここまで細かく制御できるのはスゴいね
Slack EKMを利用するには、Slack Enterprise GRIDへのアップグレードが必須です。どのSaaSもそうですが、最上位プランが最も保護され、最も手厚くサポートを受けられます。勝手にセキュリティ機能が進化していくのも最上位プランです。
セキュリティに対するSlackの投資
8月6日には、このプランに対するセキュリティ強化の機能発表がされました。
- 副次認証制御
「Face ID」や「Touch ID」、セキュリティの追加レイヤとして生成されたパスコードを用いた多要素認証を、更なる追加認証として利用できる。 -
セッション管理ツール
機器の紛失や盗難が発生した際、管理者はAPIを通じて特定ユーザーに関連付けられるモバイル機器やデスクトップ端末のセッションを遠隔地からワイプできる。 -
ドメインのホワイトリスト化ツール
管理者は、承認されていないワークスペースに従業員がサインインすることを防止するために、企業ネットワーク内でアクセスできるワークスペースを指定しておける。 -
モバイル機器へのファイルのダウンロードやメッセージのコピーを制限するオプション
スマホ利用での細かな制御
更に今後、
- セッション管理制御が管理者向けダッシュボードに追加
- 1度にログインできるデバイスの最大数
- ジェイルブレイク検知とデバイスを守るためのアクセスブロック
- アプリのアップグレードを要求
- IPアドレスが未承認のデスクトップ端末からのファイルのダウンロードのブロック
- モバイルブラウザ管理機能（Slackで共有されるすべてのリンクをモバイルアプリケーション管理（MAM）のコンテナ内で管理されている特定のブラウザーで開くよう制御）
なども発表されています。
SaaSの全てに言えることなんだけど
本来提供するサービスと並行して、セキュリティ機能そのものを開発して提供したり、セキュリティ運用に投資できる事業者は、どう考えても強い。