ドーモ、ミナサン。 estie SRE の sugitak です。趣味は DNS です。
さて、突然ですが、みなさんは AWS のセキュリティと言われて何を考えますか？
Security Hub でしょうか。 GuardDuty や Config でしょうか。あるいは、認証情報（IAM）や MFA でしょうか。アカウントを現実的に守るためにはこれらの設定が必須ですね。しかし、今日お話ししたいのは「責任共有モデル」についてです。
AWS のセキュリティについて調べようとすると必ず最初の方に出てくる「責任共有モデル」。 AWS セキュリティのスタート地点と言って差し支えないでしょう。しかし私は以前から困っていることがありました。
「この責任共有モデル、どう使えばいいの？」「なぜ重要なの？」
この疑問は全社セキュリティに携わるようになって解決したのですが、この問いに答える情報を見つけることが難しく、当時の自分はかなり遠回りをしてしまいました。今回、セキュリティ仕事を始めたばかりのころの自分に向けて、そんな責任共有モデルに至る前の、そもそもセキュリティって何だっけの話をしていきたいと思います。
今日するお話
- 会社にとって、セキュリティはお金の話だよ
- 会社はセキュリティを守れていることを証明する必要があるよ。それがガバナンスだよ
- クラウドサービスはアウトソーシングだよ。データを預けるリスクを評価する必要があるよ
- 「どこまでアウトソースしているか」を示すのが責任分解モデルだよ
- サービス提供したら説明責任はこちらにあるよ
今日する話はこれくらいです。
セキュリティはお金の話
会社にとって、セキュリティとはなんでしょうか。重要情報を守ることでしょうか。
……はい、タイトルに書いてある通りですね。セキュリティというのはお金の話です。
どのようなリスク（どの程度の確率でいくらの損害が出るか）に対処するために、いくらの投資をするのか。会社というのは収益を上げることを目的としている以上、経営においてはセキュリティもその尺度で判断されることになります。セキュリティ部門には、個々のリスク対策や事業、サービス利用などについて経営判断ができるよう、それをコストの話に落とし込むという重要な役割があります。
極端な話をすると、攻撃されたとしても企業価値を毀損しないのであれば、守らないという判断もあり得るわけです。じっさい、アタックを受けたあとの対応が素晴らしかったことで株価がむしろ上がった会社というのは少なからず存在します。
（もちろん、しっかりした事後対応は平時からの社内の環境整備や文化整備、体制、関連機関や当局との関係性の構築などがあってこそできるものなので、「セキュリティ投資をしなくても大丈夫！」ということは実際は全くありません）
セキュリティを完璧な状態にしたいというのは誰しも思うことだと思いますが、現実的には人員や金銭、時間や優先度を考えると困難ですし、そもそも「100% の状態」というものはこの世に存在しません。したがって、どういうリスクに対してどう対応していくかを整理することが必要です。
ここをノーヒントで自力でやっていくのは非常に難しいですが、補助線として使えるものとして、セキュリティフレームワークがあります。例として、 NIST Cybersecurity Framework (CSF) なんかがあります。 CSF v1.1 では、組織におけるセキュリティの機能を、識別・防御・検知・対応・復旧の5種類に分けています（2023/03/31 デジタル庁の和訳）。
こういったフレームワークのようなものを参照することで、どういうリスクに対してはどの程度の「防御」が必要かであったり、「識別」段階がどの程度徹底されているかなどと整理し、自社のサービス等のセキュリティがどのレベルにあるのか、次に何をするべきなのか、いくらの費用まではかけても良いのか、判断するための筋道を得られることになります。
全社セキュリティは、このようにして、最終的にはお金という共通言語を介して経営判断されていくものです。
ここまでのお話
- 会社にとって、セキュリティはお金の話だよ
セキュリティガバナンスの確保
さて、全社的なセキュリティはお金の話でした。その全社セキュリティを各社員に落とし込むにはどうすればいいでしょうか？
……はい、タイトルにある通りですね。ガバナンスです。
ガバナンスとはなんでしょうか。よく日本語では「統制」と訳されますね。少し怖いもののイメージがあるのですが、その語源は「操舵」を意味する古代ギリシャ語、 “Kubernan” 。そう、 “Kubernetes” と同じなんです。Kubernetes のマークは船の舵でしたね。クラスターという大きな船団を動かす舵が Kubernetes 。会社という大きな組織を動かす舵が、ガバナンスなんす。
ガバナンスは広い概念です。株式会社のコーポレートガバナンスという文脈であれば、会社が不正を行わないよう株主が社外から監査する仕組みのその全体を表します。今回は、もう少し狭い「セキュリティガバナンス」だけをみています。
セキュリティガバナンスについて、好きな表現があります。「自分たちで決めたルールを自分たちで守っていると証明すること」というものです。自分たちで定めたルールについて、有事に外部へ説明し、平時にはセキュリティチェックシートへ回答をできる状態にしておくことがセキュリティガバナンスである、という捉え方。スタートアップのセキュリティに関わっている身としては実感と非常に近いですし、自分ごととして前向きに捉えるこの表現はとても良いなと思っています。
セキュリティのルールを定めることは簡単です。しかし、それを運用し続けること、守り続けることはとても難しい。ルールはすぐに忘れられ、形骸化します。形骸化させないためには、仕組み化が必須です。
「AWS アカウントは GuardDuty を全リージョンで有効化する」とルールを定めたとします。あなたの組織では、どのようにその状況を保証しますか？
「USB メモリは使用しない。ただし情報システム部に許可されたケースに限り使用してよい」だったらどうでしょうか？
あるいは「ディスクは全て暗号化し、廃棄時には指定の業者を用いること」はどうでしょうか。本当に「全て暗号化」されていたこと、廃棄時に指定の業者を用いていたことをどう証明しますか。
これらはいずれも、機械的な仕組み化で保証できる部分が多いことでしょう。しかし、一つひとつのルールを全て仕組み化しようとしても、ルールというのは山ほどあり、仕組み化には結構な労力がかかりますから、カバーしきれない部分は必ず出てきます。そして、そういったところは運用ルールや社内手続きで賄うことになります。
面倒な社内手続きに出会ったら、ガバナンスを維持するために奮闘している人たちのことを思い出してください。労務とか経理とか法に基づいて組織の番人をしているわけで、それって知識持って毎月の運用を完璧に回しているって意味で、マジ神ですからね。
ちなみに、時折ガバナンスと混同される言葉としてコンプライアンスがありますが、こちらは英語 comply 「（命令・規則などに）従う」です。法律や社内規則などを守ることを意味します。
元の単語が comply なので、具体的な何かの規則を守ることが意図されていることには注意が必要かもしれません。「昨日の飲み会のあの人の発言、コンプラものだよ〜」みたいな使い方は、じつはちょっと気になる系の細かい性格していてすみません。
話がズレました。全社でのセキュリティを保つためにルール（社内規則）があり、そのルールが守られていることを証明するためにガバナンスがある、というお話でした。
ここまでのお話
- 会社にとって、セキュリティはお金の話だよ
- 会社はセキュリティを守れていることを証明する必要があるよ。それがガバナンスだよ
クラウドサービスの評価とは？
さて、徐々に話が「AWS を使うこと」に近づいてきました。
新しいクラウドサービスを利用する際、そのサービスが安全かどうかを確認する社内手続きが必要……ということをした経験はありませんか。私は AWS や GCP の利用時含め、何度もあります。 AWS なんか NASA だって NSA だって金融機関だって使ってるのに今更確認なんて、と思うかもしれません。これは何のために必要なのでしょうか。
これは結構シンプルで、「クラウド」というのがあまりに広い範囲の話だからです。 AWS も Confluence も Salesforce も、 Heroku も BugSnag も Miro も、個人が GitHub 開発を便利にするためにちょっとだけ作った bot サービスも、 IaaS, PaaS, SaaS, FaaS まであらゆるものが「クラウド」と呼ばれてしまっています。
クラウドセキュリティについて米国連邦政府が書いた名ドキュメント NIST SP 800-144 [IPA和訳] を読むと、クラウドサービスはあくまでアウトソーシングの一種であり、その利用にあたっては自社に説明責任があるのだと述べられています。アウトソーシング。つまり、細かいことを抜きにすると、 AWS だって契約上は「サーバを運用して中身を貸している会社」である、ということです。
AWS は高いセキュリティの実装と倫理観・使命感をもってこれまで運用を続けてきています。エンジニアにとって、これを信用するのは自然なことです。しかし、それは AWS を「アウトソースではない」と言うための情報ではなく、むしろ「アウトソース」の関係を前提としたうえで AWS を信頼できるという情報なんですね。
会社のセキュリティ部門は、経営陣に報告するために、そんな千差万別なアウトソーシングサービスの利用によるリスクとベネフィットを把握する必要があります。クラウドサービス評価は、その把握のためにあります。
信頼できないサービスを利用した場合のリスクには、どんなものがあるのか。具体的には、以下のようなものがあり得ます：
- AIサービスに自社の機密情報を入れたら、その機密情報が学習され、他のユーザに利用できる状態になった
- サービス上で個人情報を取り扱ったら、現地法に違反してしまい、アカウントがサスペンドされたうえ莫大な罰金が発生した
- 宅配便チェッカーをメール連携させたら、自分のメールから機密情報が流出した
- 過去に AWS 連携させたサービスを放置していたら、そのサービスが乗っ取られ、 AWS アカウントが侵害された
- 自社の個人情報がそのまま外国に売り渡されていた
輸出制限を考えないといけないケースなんかも考えられ、リスクの可能性は無限にあります。こういったリスクがさほど高くないサービスももちろん多いのですが、もし可能性があるとするとどういうものがあるのか。これをセキュリティ部門は把握する必要があるわけですね。
余談：個人情報の「委託」にあたるのか？
クラウドの利用はアウトソーシングだ、と述べました。では、個人情報を AWS に預けた場合、それは個人情報保護法上の「委託」にあたるのでしょうか？
個人情報保護法の観点から見ると、 CSP(Cloud Service Provider; クラウドサービス事業者) が預けられた個人情報を「取り扱わない」場合には委託にはあたらないこととなっています（個人情報保護委員会 FAQ Q7-53 参照）。たとえば S3 上に置いた場合、 AWS のサポートはこれを閲覧する権限を有しませんので、ただちに委託となるわけではない、とみられるでしょう。（正確な話をするためには利用規約の確認が必要です。必ず自社の法務担当とご相談ください）
ここまでのお話
- 会社にとって、セキュリティはお金の話だよ
- 会社はセキュリティを守れていることを証明する必要があるよ。それがガバナンスだよ
- クラウドサービスはアウトソーシングだよ。データを預けるリスクを評価する必要があるよ
責任分解モデル
ここにきてやっと、責任分解モデルに到達しました！
https://aws.amazon.com/jp/compliance/shared-responsibility-model/
セキュリティとコンプライアンスは AWS とお客様の間で共有される責任です。この共有モデルは、AWS がホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素を AWS が運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。お客様には、ゲストオペレーティングシステム (更新とセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、および AWS が提供するセキュリティグループファイアウォールの設定に対する責任と管理を担っていただきます。使用するサービス、それらのサービスの IT 環境への統合、および適用される法律と規制によって責任が異なるため、お客様は選択したサービスを慎重に検討する必要があります。また、この責任共有モデルの性質によって柔軟性が得られ、お客様がデプロイを統制できます。以下の図に示すように、この責任の相違は通常クラウド “の” セキュリティ、およびクラウド “における” セキュリティと呼ばれます。
曰く。 AWS は物理セキュリティをやります。また、アクセスコントロールもユーザに渡します。クラウド利用者は提供された機能をうまく使って、クラウドのセキュリティを確保してね。
日常的にクラウドを使っていると、もはや「そうですね」という感想しか浮かんでこないほど、当たり前なことになってきました。これをセキュリティ目線で見てみるとどうでしょうか。
先ほど紹介した NIST SP 800-144 （IPA和訳）の冒頭、エグゼクティブサマリを見てみましょう。このサマリ内の見出し5つは、端的にこの文書の中身を示しているわけですが、その5つを並べると：
- クラウドコンピューティングのソリューションを利用する前に、セキュリティとプライバシーの諸側面について慎重に企画すること
- そのクラウドプロバイダが提供するパブリッククラウドコンピューティング環境を理解すること
- クラウドコンピューティングというソリューションが組織のセキュリティおよびプライバシー要求事項を満たすことを確認すること
- クライアント側のコンピュータ環境が、組織のクラウドコンピューティングに関するセキュリティおよびプライバシー要求事項を満たすことを確認すること
- パブリッククラウドコンピューティング環境に導入・展開されているデータおよびアプリケーションのプライバシーとセキュリティに対する説明責任を果たすこと
このようになっています。クラウドサービスを使うにあたって、経営陣に対して報告できる状態を作るためにセキュリティ部門はこういったことをする必要がある……そう NIST SP 800-144 は主張しているわけですね。
そして、二番目の見出しのすぐ下には以下の文章があります。
そのクラウドプロバイダが提供するパブリッククラウドコンピューティング環境を理解すること
組織とクラウドプロバイダの双方の責任は、利用するサービスモデルによって異なる。クラウドサービスを利用する組織は、コンピューティング環境に対する責任の分担と、セキュリティおよびプライバシー関連の影響について理解しなければならない。
サービス利用のアウトソースについて、その事業者がどこまで責任を負っているか、あるいは利用者側がどこから責任を持たなければならないか。ここを把握するところがそのクラウドサービスを利用する際のセキュリティ上のスタート地点になっている……そういうことがここから読み取れることと思います。
事業者と利用者との責任分解点を明確にすること、それすなわち、責任分解モデルです。
クラウドセキュリティをよく理解した人にとって、 AWS にもっとも提供してほしい情報というのが、この責任分解モデルの図になるのですね。
AWS が責任共有モデルを最重要項目として説明してくれるのには、こういった背景があったのでした。
ここまでのお話
- 会社にとって、セキュリティはお金の話だよ
- 会社はセキュリティを守れていることを証明する必要があるよ。それがガバナンスだよ
- クラウドサービスはアウトソーシングだよ。データを預けるリスクを評価する必要があるよ
- 「どこまでアウトソースしているか」を示すのが責任分解モデルだよ
責任分解モデルの使い方
さて、そんな責任分解モデルですが、どのように使うと良いのでしょうか。あなたが構築している ECS 上のサービスに対して、例えばデータセンターへの侵入対策についてセキュリティチェックシートで問われた際、「AWS の責任です」って書いて終わりにできるのでしょうか？
はい。そうですね。これはもちろん NO です。
クラウド利用者が AWS を用いてサービスを提供しているとき、そのサービス提供者はあくまでクラウド利用者であり、 AWS ではありません。 AWS 側で起きることであっても、サービスの利用顧客に対する責任はクラウド利用者が負うことになります。
これについては NIST SP 800-144 に再三にわたって記載があります。
2. 背景
2.3 アウトソーシングおよび説明責任
パブリッククラウドに移行する一番の動機は、コストを下げ高い効率性を実現することにあるが、セキュリティに対する責任を放棄するための移行であってはならない。最終的に、組織は、パブリッククラウドの選択と、アウトソーシングしたサービスのセキュリティとプライバシーに対して責任がある。
5. パブリッククラウドのアウトソーシング
5.2 事前の実施事項
◾️ セキュリティおよびプライバシー関連リスクを評価する(Assess Security and Privacy Risks)
アウトソーシングによって組織は業務上の責任から解放されるが、パブリッククラウドサービスの利用に伴うリスクについては、組織が自己防衛する必要がある。
6. むすび
パブリッククラウドの実装におけるセキュリティおよびプライバシーに関する説明責任は、クラウドプロバイダに委譲することはできず、組織が果たすべき義務である。
クラウド利用者には、サービスの利用顧客に対する説明責任があります。顧客からのチェックシートに対して「うちには責任ないよ」と受け取られるような書き方をするべきではありません。たとえ責任分解モデルにおいて AWS 側の責任とされている部分であっても、その AWS を選択したのはクラウド利用者の責任です。その点を認識していない回答はまずい、ということですね。
では、どうするのが良いか、というと、一例として「データセンターには、信頼性の高い AWS の DC を用いています」というような表現であれば、お客様のリスク管理に対して一定の回答をできるのではないかと思います。
ちなみに AWS の DC セキュリティの説明は https://aws.amazon.com/jp/compliance/data-center/perimeter-layer/ などを参照してください。より詳細な情報の提供が必要な場合、 AWS Artifact からのダウンロードをご検討ください。
ここまでのお話
- 会社にとって、セキュリティはお金の話だよ
- 会社はセキュリティを守れていることを証明する必要があるよ。それがガバナンスだよ
- クラウドサービスはアウトソーシングだよ。データを預けるリスクを評価する必要があるよ
- 「どこまでアウトソースしているか」を示すのが責任分解モデルだよ
- サービス提供したら説明責任はこちらにあるよ
まとめ
さて、今回は『AWS セキュリティ「以前」の話』と題しまして、責任共有モデルに至るまでに必要な考え方をざっと説明しました。
AWS の利用というのはアウトソースであって、そのためその利用にあたっては責任範囲を明確にしなくてはならない。そのラインを示すのが責任分解モデル。運用にあたっては責任分解モデルにしたがって業務のアウトソースが可能だが、 AWS を利用していることの責任は AWS ではなくクラウド利用者が持つことになる。ということですね。
セキュリティの専門家にとってはあまりに当然なこととなっているかと思いますが、過去の自分にとってはまったく自明なことではなく、数年くらい「わかんねーなー」ってボケーっとしていました。今回、この記事をインターネットの海に放流することで、同じように悩んでいる何人かに届いたらいいなと思います。
ところで estie ではセキュリティやネットワークに熱意を持ったコーポレートエンジニアを本気で！募集しています。興味のある方はぜひご連絡ください！
