Amazon Web Services ブログ

責任共有モデルとは何か、を改めて考える

本Blogは、クラウドにおける新しい常識”new normal”を考えるBlogの第二弾です。（第一弾「クラウドにおける安全なデータの廃棄」はこちら）
今回は、クラウドの基本的な考え方である”責任共有モデル”をとりあげます。こちらのBlogをご覧の皆様の中には”何故、いまだに責任共有モデルなのか”という疑問を持つ方もいらっしゃるかもしれません。しかし、未だに本モデルの考え方や実際のビジネスへの適用方法は十分に理解されていないようにも見受けられます。今回は責任共有モデルとは何か？を振り返るとともに、いくつかの理解のポイントをお伝えします。

セキュリティ責任共有モデルとは？

”セキュリティとコンプライアンスはAWSとお客様の間で共有される責任です。この共有モデルは、AWSがホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素をAWSが運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。お客様には、ゲストオペレーティングシステム (更新とセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループファイアウォールの設定に対する責任と管理を担っていただきます。使用するサービス、それらのサービスの IT 環境への統合、および適用される法律と規制によって責任が異なるため、お客様は選択したサービスを慎重に検討する必要があります。また、この責任共有モデルの性質によって柔軟性が得られ、お客様がデプロイを統制できます。以下の図に示すように、この責任の相違は通常クラウド ’の’ セキュリティ(Security ‘of’ the Cloud)、およびクラウド ’における’ セキュリティ(Security ‘in’ the cloud)と呼ばれます。”

責任共有モデルを踏まえたセキュリティ効率性の改善

責任共有モデルを適用するうえでのメリットを考えてみましょう。例えばお客様がPCI DSS等の認証の取得を考えた場合、全ての要件を自社で管理を行うことは非常に負荷が高く、コストもかかる作業となります。AWSはPCI DSSを含めた様々なコンプライアンスプログラムや第三者認証に取り組んでおり、お客様は自らの認証の範囲からデーターセンターの物理的な統制を除外することができます。お客様はAWS Artifactからリポートを入手することで、物理統制の評価が可能となります。この場合、認証の範囲を縮小することは審査だけでなく運用上の負荷においても大きな便益をお客様にもたらします。
同様にAWSのサービスを考えた場合、Amazon EC2インスタンスにサービスを構築する場合と、Amazon RDSなどのマネージドサービスやAWS Lambdaなどのサーバレスアーキテクチャを活用してサービスを構築した場合では、パッチの適用やバックアップ管理等、セキュリティに関連する負荷は大きく異なります。サービス自体やセキュリティ管理策に対する運用の経済性を考えた場合、AWSにセキュリティ管理を任せることで、お客様はその分の投資をサービスの改善やより重要なワークロードに振り分けることができることになります。つまり、組織がガバナンス上で何を重要とするかといった考え方に基づき、選択肢を持つことが可能となります。

AWSは”クラウド内のセキュリティに対する責任”を助けないのか。

上記のモデル図で考えた場合、責任の分界点として、”ユーザのセキュリティに対してAWSは何もしてくれないのか”という疑問をもたれるケースがあります。もちろん、そうではありません。AWSは様々な手段でお客様のセキュリティの実現を支援します。第一に、AWSは豊富なセキュリティサービスや機能、アップデートを提供しています。AWSにおける脆弱性の発見等はセキュリティ速報に公開され、お客様はRSSフィードで購読することが可能です。これらにより、お客様は自らのニーズにあったセキュリティの実装や対応を行うことができます。次に、開発者ガイドや各種ホワイトペーパーなどをもとにお客様のセキュリティに対して必要な情報を提供しています。また、単に設定方法を伝えるだけではなく、Well Architectedフレームワークは、クラウドの特性を活かしたサービスの原則を提供することで、お客様のセキュリティを支援する道具になります。
また、支援は機能やサービスだけではありません。AWSではSolution Architectによる技術支援やProfessional Servicesによる有償コンサルティングサービスの提供、Certification and Training teamによるトレーニングサービスの提供、AWS Supportによるお客様課題の支援や対応窓口の提供など、様々な形での組織的な支援を行っています。例えばAWS Supportではナレッジセンターとしてお客様からのお問い合わせの頻度の多い質問に対する回答を公開しています。
また、お客様がコンプライアンスに準拠した環境でサービスを設計、運用するためには、実際の構築や運用の担い手となるパートナー様の尽力が不可欠です。政府機関における「政府機関等の情報セキュリティ対策のための統一基準群」に対するリファレンスや金融業界における「FISC安全対策基準」へのリファレンス等は、AWSJの協力に基づきAPNパートナー様により開発、公開されており、システムインテグレーターや開発、運用事業者はこれらを活用することが出来ます。
このようにAWSは組織的、技術的に様々なアプローチでお客様のセキュリティをサポートする手段を提供しています。

多くの”責任共有モデル”は二階層ではない。

上記のモデル図は”AWS”と”お客様”の二階層で責任共有を表現しています。しかし、様々な場合において、二階層で責任共有モデルを考えることは現実的ではないことがあります。例えば、日本では多くの調達や開発、運用において、システムインテグレーターや開発、運用事業者が存在する場合がありますし、例えばお客様がSaaS事業者と契約した場合、そのインフラストラクチャをAWSが提供している場合があります。こうした場合、セキュリティは重層的になります。実際にはお客様の中でも様々な責任共有の形があります。また、お客様の中にも責任共有モデルは存在します。事業部門とシステム部門、監査やリスク管理部門など、単一の組織においてもセキュリティの責任は複数の組織で共有しているものとなります。責任の範囲を明確にすることは本来は自然なことであり、まずは範囲を明らかにした上で、どのように協働をおこなうかというプロセスが重要になります。

重層的な責任共有モデルにどう向き合うか

お客様がSaaS事業者やシステムインテグレーターと契約した場合、セキュリティに対する説明責任はそのような事業者自身がAWSが提供する様々な情報を活用してお客様と向き合うとともにセキュリティの実装などに責任を持つことになります。こうしたパートナー様のエコシステムの育成や拡充のために、APNパートナープログラムではセキュリティコンピテンシーやパブリックセクターコンピテンシー等、お客様が業界や技術に明るいパートナーを選択できる仕組みを提供しています。既にご説明したAPNパートナー様によるセキュリティリファレンスなどの取り組みも進展しています。また、お客様の中における責任共有モデルにおいても、AWSでは実際にお客様の様々なクラウド移行を支援してきた経験から、お客様内におけるクラウド推進組織であるCloud Center of Excellence (CCoE）の設立などをベストプラクティスとしてお客様にお伝えしています。

責任共有モデルは”セキュリティだけ”のものではない。

このような責任共有という考え方は、”セキュリティだけ”に適用されるものではありません。例えば、ある情報システムのクラウド移行を想定した場合にも、“移行計画”の策定、“予算”の見積もりと確保、“クラウド要件”の定義、“調達/購買”の実施、（特に公共部門の場合には）“契約”の締結、実際の“精算”・・といった一連のプロセスが伴います。ここで注目すべきは、ユーザ側・調達者側が上記の一連のプロセスにおいてガバナンスを強化することが望ましい「new normal」においては、従来のモデルとは責任主体や責任の共有の仕方が異なるケースが頻発する、ということです。例えば：

  •  “予算”の見積もりと確保──クラウドのコストメリットは、従量課金により実際に使った分だけを支払うことができる点に求められます。旧来の情報システムの発注は、その運用までも含め、固定額で見積もられることがほとんどでした。しかしクラウドを前提とした予算の確保では、ユーザ側・調達者側が積極的にクラウド利用料金の実績値管理（その頻度は週次であったり、日次で行うことも可能です）に主体性を持ち、次年度（場合によっては次期四半期）の予算確保の精度を継続的に上げていくことが求められます。ツールとしてはAWS Cost Explorer等が役立つはずです。
  • “調達/購買”の実施──旧来の情報システムの“調達/購買”においては、システム・インテグレーター（SI）によってシステム構成要件の全てを満たすことが期待されていました。しかしクラウドを前提とした調達/購買においては、これらの要件をSI/AWS/調達者の三者（あるいは、リセラーを含めた四者）によって分担し、共有することが必要となります。SIに求めるべきことをクラウドサービス事業者に求めるべきではなく、その逆もまた然りであるため、両者には別途独立した要件を求めることが妥当です。
  • 利用料の“精算”──従量課金であることはクラウドのもたらす大きな利点の一つですが、例えば当初想定した予算枠の「上限を超えてしまったらどうすればよいのか」とのお問合せをいただくこともあります。旧来の慣習では、SIが予算超過・納期遅延の赤字を飲み込むという「解決策」もあり得たのかもしれませんが、クラウドの時代における正攻法は、予算のしきい値を超えたときにアラートを発信するAWS Budget等のサービスを用いて、予算管理におけるガバナンスを高め、上限超過を未然に防ぐことです。それと同時に、公共のお客様の場合には「変更契約」や予算費目間の柔軟な流用・充当の場面に備えるなど、超過分に対する補填の仕組みを組織内部で整えていただくことが近道の場合もあります。
  • ガバナンス向上への工夫 ── お客様は、多数の情報システムを運用しています。その際にサービス利用に関わるAWSアカウントの所有（自ら保有する、もしくはリセラー等の保有環境を利用する）に対する選択を行うことが出来ます。また、アカウントを横断したコストや運用の一元化を実行することも可能です（AWS Organizationsが役立つはずです）。このような工夫により、複数の情報システム横断的かつ部局横断的な利用傾向の可視化と合理化を実現することが可能となります。また、TAM（Technical Account Manager）を自社のCloud Center of Excellence (CCoE)のアドバイザーとして用いることでの知見の蓄積など、ガバナンスの向上を加速することが可能です。

なお、セキュリティ以外の分野に対する責任共有モデルの適用の詳細は、『 AWS “予算・調達・契約・精算”の責任共有モデル（仮）』と題しまして、近日中に別の投稿にて皆様にご案内させていただく予定です。

まとめとして

”責任分界点を明らかにして、それを共有する”という考え方は、特別なものではなく、契約行為や組織において自然なものです。責任の所在を曖昧にすることは、様々なサービスや事業者の価値を活かすうえでの障壁となることがあります。何を目的としてクラウドを活用するのか、どのような価値を期待するのかを考える上で責任共有モデルを理解することは大きな一歩となります。
本Blogで示した様々な情報や考え方が皆様のサービスの価値向上のお役に立てば幸いです。

このブログの著者
松本　照吾（Matsumoto, Shogo）
セキュリティ アシュアランス本部 本部長
小木　郁夫（Koboku Ikuo）
パブリックセクター 統括本部長補佐（公共調達渉外担当）