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