【資料公開】 組織的なクラウド統制のはじめの一歩（前半）

本ブログは 2023 年 4 月 5 日に開催された 組織的なクラウド統制を成功させるための勘所～ CCoE の取組事例と最新サービス活用術をご紹介～ におけるセッション「組織的なクラウド統制のはじめの一歩」の資料公開、およびブログ版です（後半の技術的な内容は別ブログです）。

 

CCoE、もしくは、組織内のクラウド利用の統制を始めたい方向けの内容になっており、AWS アカウントやユーザー、セキュリティ、ログの管理について記載しています。

登壇資料の目次

1. CCoE の取り組み 本ブログで紹介
2. AWS 利用ルール（利用ガイドライン）の策定 本ブログで紹介
3. AWS のクラウド統制サービスの紹介 別のブログ

本ブログは技術的な要素は少ない前半部分となります。後半部分の技術的な「AWS のクラウド統制サービスの紹介」は下記ブログで資料公開されています。

CCoE の取り組み

CoE (Center of Excellence) とは、特定分野におけるトップレベル人材やノウハウ、設備を集約した組織であり、その Cloud 版が CCoE (Cloud Center of Excellence) です。

CoE にはクラウドだけではなく、アジャイル開発や AI 活用・データ分析などでも組織されることがあります。

CCoE は組織内でクラウドの推進と統制を円滑にできるように取り組みます。

主な取り組みには下表があります。クラウドを活用するプロジェクトを支援するのはもちろん、セキュリティ部門や経理担当、経営者とコミュニケーションを取り、社内ルールを整理してガイドラインや共通サービスを提供することもあります。また、社内だけではなく社外からの情報収集や会社のプレゼンス向上のために社外に情報発信することもあります。

組織内のデザインパターンは様々ですが、専門組織として立ち上げる場合の一例を示します。社内、および、社外のハブとして機能するイメージです。

CCoE は必ずしも新しい組織を立ち上げる必要はなく、DX 推進や技術企画部門などが上記の機能を持つことや、バーチャルチームとして結成されることもあります。その際に留意する必要があることは、1 つの組織が統制だけを目的に活動するとルールが厳しくなり過ぎる場合がある点です。統制を検討する組織もプロジェクトを推進する当事者となり、ビジネススピードと統制のバランスが取れることが望ましいです。

CCoE の取り組みは下記ブログも参考にしていただければ幸いです。

上記を踏まえた上で、本セッションでは「利用ルールの策定」と「クラウドの管理」の 2 つの統制の取り組みにフォーカスを当てて、なぜ統制が必要なのかを紹介しました。

 

AWS 利用ルール（利用ガイドライン）の策定

AWS の利用ルール（利用ガイドライン）には次のような内容があります。

この中でも始めに取り組むことが多い項目が次の内容（上段の内容）です

• AWS アカウント管理
• ユーザー管理
• セキュリティ対策
• ログ管理
• コスト管理の一部（AWS の利用料支払い、費用計上のルール）

 

AWS アカウント

AWS アカウントを一元管理できていないときの課題から紹介します。

よくあるのが下図のような各部門が独自に AWS やリセラーと契約している状況です。

このような状況でインシデントが発生したり、脆弱性の確認が必要だったりしたときには、調査する担当者は、社内のすべての AWS アカウント保有者を調べてヒアリングしなければいけなくなります。かなりの手間です。

状況確認が終われば、次は対策も同様に全ての担当者にお願いする必要があり、同じような手間が発生します。

また、インシデントが起きた時点では全てのアカウントで十分な対策をするのですが、その後に契約された AWS アカウントでは対策が実施されないケースがあります。

これらに対応するために、AWS の組織管理サービス（AWS Organizations）を用いたアカウント一元管理があります。

AWS Organizations ではAWS アカウントをグルーピングし、グループ毎に統制ルールを導入できます。また、CCoE がアカウントを集中管理して社内で発行するルールとすることで、発行時に組織のポリシーに合った必須の設定（セキュリティ関連の設定など）を実施できます。インシデントが起きた際にできた対策も新しいアカウントに漏れなく反映できます。

 

ユーザー管理

AWS の IAM ユーザーを一元管理できていないときの課題から紹介します。

IAM ユーザーを各アカウントで管理している際には次のような課題があります。

• 同じ利用者の IAM ユーザーを各アカウントにそれぞれ作成しており、管理負荷が高くなる
• 各アカウントでポリシーが異なることから、MFA 未設定＋脆弱なパスワードのユーザーが存在してしまい、乗っ取り被害に合いやすくなる
• 異動・退職したユーザーが残り続けており、管理されていない

これらに対応するためには、統一したポリシー（パスワードポリシーや MFA の必須化など）で運用するためにユーザーを一元管理することです。退職や異動にも対応しやすくするために、既に組織内で導入済みの ID 製品（Azure AD など）と連携させるアプローチもあります。

既存の ID 製品と連動させる際は CCoE だけで完結するのではなく、Azure AD 等を管理する情報システム部門との連携が必要となる場合もあります。

 

セキュリティ対策

AWS のセキュリティ対策には「予防的統制」と「発見的統制」の考え方があります。

予防的統制のイメージです。よく車のガードレールに例えられるのですが、許容できない操作を大枠で禁止して、ルール内では基本的に自由に利用させます。厳しい条件で操作を禁止するとビジネススピードを落とす懸念があるため、後述する発見的統制と組み合わせるなどしてバランスを取りつつ対策します。

発見的統制のイメージです。好ましくない設定や誤設定に気づく仕組みや危険な通信・不審なアクセスに気づく仕組みを導入します。例えば、下記のような設定や危険な通信の検出です。

実現方法には、AWS 提供のセキュリティサービス（AWS Security Hub や Amazon GuardDuty）を利用する方法やサードパーティのセキュリティ製品・SaaS を利用する方法があります。

導入にあたり、どのような制限内容や検出条件にするかのルール決めも必要となります。その検討には AWS の知見が必要となるため、CCoE などの AWS の技術に精通したメンバーがセキュリティ部門と連携して対応することで効率よく進めることができます。さらに、CCoE が実際にプロジェクトを支援した経験（またはプロジェクト対応経験）があることや社内の要望を把握しておくことで、ビジネススピードとセキュリティのバランスも取りやすくなります。

 

ログ管理

複数アカウントのログをログアーカイブ用のアカウントに集約することがあります。

下図はユーザー操作などを記録する AWS CloudTrail のイベントログを集約している例です。

ログ集約の目的としては次のような内容があります。

• ログの保全（安全な場所に隔離）
• ログの分析

ログを隔離していくことで、1 つのアカウントが乗っ取り被害にあった場合でも、隔離先アカウントのログから調査することができます。

この際、ログ転送元アカウントとログ集約アカウントの管理者が異なる場合は、転送元アカウントにもログを残す対応をすることもあります（サービスによっては追加料金が発生します）。

集約したログは SIEM や BI ツールを用いて分析したり、見える化したりすることもあります。利用する製品によってはログを集約せずに、各アカウントから直接ログを転送できる場合もあります。

 

コスト管理の一部

コスト管理では、料金を細かく確認して削減するための施策を実施することもありますが、スキルが必要なこともあるため、必ずしも始めから取り組まなければいけないものではありません。

はじめに検討しなくてはいけないのでは組織内の請求・支払いの役割分担と費用計上ルールの整理です。

例えば、次の整理事項があります。

• アカウントを一元管理した際の請求フロー
  • CCoE が一括払いをして組織内の他部門に費用を振り替えるのか
  • もしくは、各プロジェクト単位・部門単位でそれぞれ支払い処理をするのか
• Reserved Instance (RI) などの前払いサービスの費用計上ルール
  • 例えば、前払い分を毎月の支出に振り替えるなどのルール

 

ちょっと宣伝

組織内のクラウド利用ルールをクラウド利用ガイドラインとして策定することがあります。

クラスメソッドメンバーズではガイドラインを策定する際の参考としてガイドラインのサンプルを掲載した「Classmethod Cloud Guidebook」をメンバーズのお客様向けに提供しています。

既にクラスメソッドメンバーズのお客様は、クラスメソッドメンバーズポータルサイトの「お役立ち情報」→「組織的な AWS 活用のノウハウ」から閲覧できます。ぜひご活用ください。

紹介ブログは下記となります。

 

さいごに

CCoE の取り組み内容と AWS の統制をするために始めに取り組むことが多い内容を紹介しました。

このブログがどなたかのご参考になれば幸いです。