はじめに
本記事は、Supershipグループ Advent Calendar 2022の23日目の記事です。
CCoEという言葉をご存知でしょうか？
今話題のChatGPT1に質問すると以下の回答が返ってきました。
少し説明が不足しているので補足すると、先頭のCはCloudのCを指しています。
すなわちCCoEとは、CloudとCenter Of Excellenceを組み合わせた造語です。
IT業界ではCloudの推進組織という意味合いでDXと並びCCoEという言葉が使われています。
CCoEについて以前書いた「Cloud Center of Excellenceとは何か」もご参考にどうぞ。
私は今の会社にJoinして、新しい組織の設立とともにCCoEの立ち上げ及び運営が最初のミッションでした。
CCoEという言葉は事前に調べてはいたもの（前述の記事）、実際にやってみると色々と苦難の連続でした。
本記事では、CCoEの立ち上げから運用に至るまでのプロセスや、実際にCCoEとして活動した1年の振り返りについて記載しています。
題材にしているパブリッククラウド（以下、クラウド）はAWSですが、Google Cloud Platform（GCP）にも適用できる考え方もあるので、これからCCoEを一から構築する方や、何らかの形で関わっている方々の参考になれば幸いです。
なぜCCoEが必要なのか
CCoEの必要性は、組織の事業及びクラウド利用の規模によって異なるため、一概には言えません。
当社の例では、以下のような背景を踏まえて、事業の多くがクラウドを中心に行われていることや、組織の拡大が進んだことで、CCoEの必要性は必然だったのではないかと思います。
- 様々な事業が行なわれているが、それぞれ事業スキームが異なる
- M&Aを繰り返すことで組織が大きくなっているため、全てにおいて統一されたカルチャーが存在しない
- クラウド利用に関する社内のルールが存在しないため、セキュティやガバナンスなど様々な課題が顕在化
要約するとCCoEの意義は、ピーター・ドラッカーの有名な著書『マネジメント』2のまえがき-「なぜ組織が必要なのか」に記載されている以下一文に尽きると考えています。
成果をあげる責任あるマネジメントこそ全体主義に代わるものであり、われわれを全体主義から守る唯一の手立てである
GCPのコミュニティで連載されているCCoE 連載 Vol.３ なぜCCoEがクラウド活用に必要なのかも参考になると思います。
CCoEの立ち上げ
CCoEとして機能するまで、どのように始動したか主たるプロセスについて以下に記載します。
- ロードマップの作成
- 現状分析
- 課題の整理
- AWSアカウントの棚卸し
- ベストプラクティスの収集
- タスクの整理
- タスクの洗い出し
- 工数見積り及び優先順位
ロードマップの作成
はじめに行ったのは、ロードマップの作成です。
物事を進めるためには、計画が必要です。
計画がないと何を目的として、何のためにやっているのかが、分からなくなってしまうためです。
これまで培った経験を踏まえて、プロジェクト計画書と同じ要領で作成し、以下に示す項目を整理しました。
-
目的
- 課題の共通認識や、CCoEの方針（クラウド利用推進）等合意形成を図ることを目的とする
-
課題・背景
- 事業やクラウド利用に関する現状の課題について
-
範囲
- 影響を与える組織のスコープを定義
-
方針
- セキュリティ・ガバナンス・コスト最適化の各課題に対して、問題解決のビジネスフレームワークであるAs-Is/To-Be分析を用いて、現状と理想のギャップを整理する
-
ロードマップ
- クラウド利用に関する上位概念のデザインや、スケジュールなど
-
コミュニケーション
- CCoEの行うべきコミュニケーションを整理する（クラウドセキュリティに関わる情報共有/設計・開発工程でクラウドに関わる意思決定のサポートなど）
現状分析
目的と手段を混合させてはいけません。
例えば、何の考えもなく実態を可視化するために、ツール導入などを目的にした場合、結果的に待ち受けているのは不要なコスト増加のみで、何も変わらないという現実です。
このような不毛な結果に陥らないようにするためには、「本質的な選択肢」を見極める作業が重要です。
課題の整理
知的生産のシンプルな本質は、イシューからはじめることです。
CCoE立ち上げ当初は、組織ができたばかりの状況でしたが、既にControl TowerやSecurity Hubなどの管理機能は導入されている状況でした。
現状分析を進めていくに当たって、CCoEに課せられた以下の課題について、少しずつ現状が見えてきました。
-
セキュリティ
- Security Hubでセキュリティチェックを行い可視化はしているが、対応が行われていない
-
ガバナンス
- Control Towerを導入したばかりで、ガードレールなどの統制機能についてほぼ未整備の状態
-
コスト最適化
- 各AWSアカウントに対するコストの予算は決まっているもの、何故この金額なのかが不明なため、本質的な評価がしにくい
次にぶち当たった壁が、管理部門であるCCoEと利用部門である各組織との調整です。
例えばSecurity Hubで検出されたセキュリティチェックに対して、自動的に修復することは機能上実現できます。
またControl Towerのガードレールは厳しく制限しようと思えば、いくらでもできます。
CCoEの活動は、何も厳しくすることが目的ではありません。
何も考えずに、管理機能を使用してガバナンスのコントロールを行う場合は、各事業に大いに影響を与えます。
従って全体を俯瞰して、組織と調整した上で物事を進めながら、段階的に改善していくプロセスが求められます。
基本的にフルリモートで働いていますが、バーチャル組織として横断的に活動することは、まるで霧の中を歩いているような感覚です。
本記事で利用しているControl Towerなどのマネージドサービスは、以前書いた「AWSで考えるクラウドセキュリティ マルチアカウントを運用せよ」を参照ください。
（ちょうど1年前のCCoE立ち上げ時、手探りの状態の時に書いたAdvent Calendarの記事です）
AWSアカウントの棚卸し
CCoE立ち上げ後、最初にぶち当たった壁ですが、そもそも管理すべきAWSアカウントについて、情報が全く整理されていませんでした。
使用しているか、使用してないのかなど利用状況が不明なアカウントや、誰が管理者なのか不明だったり、誰に聞けば良いかも分からない状態でした。
そもそも使用していないのであれば、使用されていないAWSアカウントを削除することによって、後がやりやすくなるのでAWSアカウントの棚卸しから初めました。
最初の成果として、使用されていないAWSアカウントをいくつか葬ることができました。
これだけで、毎月無駄に発生していた不毛なコスト削減や、セキュリティリスクを低減できます。
ベストプラティクスの収集
CCoEに正解はありません。
冒頭に書いている通りに、CCoEの必要性は組織の事業及びクラウド利用の規模によって異なります。
他の会社はどうしているのか？
CCoEを立ち上げた当初は、毎日悩んでいました。
ベストプラティクスを収集するために、他社事例を調べたり、AWSのTAM3さんに相談、AWSのイベントに参加するなど色々な角度から研究しました。
以下CCoEという枠組みを形成するために、参考になった資料のリンクです。
-
概念
-
他社事例
タスクの整理
CCoEのタスク管理は、普段Backlogを使用しています。
AWSのTAMさんと共有することで、密にコミュニケーションを行うことができるようにしています。
スプレッドシートのタスク管理などではなく、使えるものはどんどん使いましょう。
なお、Backlogではタスクのことを「課題」と呼びます。
やるべき作業（タスク）と、 課題は明確に区別する必要があります。
言葉の意味を理解した上で使用しましょう。
タスクの洗い出し
準備ができたら、CCoEとしてまずは何をすべきか？タスクの洗い出しが必要です。
課題に対して、あるべき姿を想定し、そのために何が必要か？誰と調整すべきか？を考えます。
悩んだら、ホワイトボードに書き出してチームで会話することも重要です。
悩むという行為は、何も生まれないため、悩んだらどんどん周りに相談しましょう。
また課題に対する施策をTAMさんと共有することで、施策の解像度を上げることができます。
工数見積り及び優先順位
CCoEのタスク整理で難しいのは、抽象度が高いタスクが多いため、予定が立てづらく、不確実性な見積りが発生しがちなことです。
自己完結できないタスクの工数見積りを行う際は、不安量を考慮することで、見積りがしやすいと思います。
世の中コントロールできる変数と、コントロールできない定数で満ち溢れています。
横断組織として活動するために、ときには自分の力ではどうしようもない定数は一旦置いておいて、変数を見つけてコミットしていくことでモチベーションを上げやすいと思います。
CCoEの活動方針
繰り返しになりますが、CCoEに正解はありません。
CCoEを構築するためには、組織の実態に合わせて作り込む必要があります。
CCoEの活動モデル
CCoEとして活動する際は、大きく以下のようなバリエーションが存在します。
ガードレールの実態はControl Towerで用意されているコントロールリストを指していますが、Control Towerでカバーできないアクションはサービスコントロールポリシー (SCP)による制御も行なっています。
| モデル | 実現方法 | クラウドの利用方式 |
|---|---|---|
| ガバナンス重視 | ガードレール+サービスカタログ+各種手順書 | CCoEでテンプレート・メニューを用意して、利用部門ではカタログ化されたテンプレート・メニューからクラウド利用を可能とする。 |
| バランス | ガードレール+各種ガイドライン | ガードレールに違反しないアクションは許可することで、開発の自由度を最大化する。またCCoEで各種ガイドラインを整備することで、利用者に適切なクラウド利用を案内する。 |
| 権限移譲 | 各種ガイドラインのみ | ガードレールが存在しないことで、管理部門による負担は軽減されるが、リージョンやサービスの制限がないため、大きなリスクを許容する覚悟が必要である。 |
当社の場合は、バランスモデルを採用しています。
傾向として上記で紹介している他社事例を参考にすると、大規模な企業になるほど、ガバナンス重視の傾向が強くなっていると思います。
マインドセット
VUCAと言われるこの時代、今年の10月には1990年以来約32年ぶりに1米ドル=151円をつけて歴史的な円安と言われたのは、記憶に新しいです。
当然、クラウド利用には大きな影響を与えます。
なぜなら、ドル払いの場合は支払日の為替レートに基づいた請求になるためです。
このような変動性や、不確実性などへ対応するために有効な思考法は、OODAループです。
OODAループは、軍事行動から生まれた考え方ですが、ビジネスにも応用できる考え方です。従ってCCoEのような組織的な行動にも大いに活用できます。
CCoEの活動実績（1年の振り返り）
キュリティ・ガバナンス・コスト最適化の各課題より、チームで出したアウトプットについて、書ける範囲でKPTの観点から振り返ります。
-
K：Keep＝
今後も続けること -
P：Problem＝
問題 -
T：Try＝
今後、試してみたいこと
セキュリティ
ガバナンスが整備されていない状況で、CCoEの活動を行う中、一番難しい課題がセキュリティという抽象的な課題です。
理由として、上位概念となる会社の情報セキュリティに関する基本方針は存在するもの、人的なリソース以外の問題を除き、以下Pに示すような問題が挙げられます。
K
-
重要なお知らせの共有
- 各サービスのEOLなどを含む重要な情報について、CCoEから各AWSアカウントの管理者へ適切に共有することで、サービスに影響を与えないよう配慮しています。
-
全体監視によるセキュリティインシデントの早期検出
- GuardDutyで検出した脅威に対して、CCoEで情報を確認した上で、セキュリティインシデントの早期検出及びインシデント発生時の初期対応を実現しています。
P
-
共通認識の問題
- 組織で守るべき共通の開発ルールが定義されていない場合、セキュリティ対策の範囲や方針が曖昧になりやすく、脆弱性を作りやすい状態になりがちです。
-
異なるセキュリティ要件
- 事業によって案件ごとに求められるセキュリティ要件が異なるため、担当者はどこまで対策すればよいかがわかりにくいという状態に陥りやすいです。
T
-
DevSecOps
- これまで後工程で行っているセキュリティ対策のプロセスを、開発工程の早い段階に組み込む様、組織としての考え方を変えていく必要があります。
-
脆弱性管理の見直し
- 脆弱性管理は、CCoEの活動範囲を超えて、CSIRTなどセキュリティに関わる組織や、各組織との連携が重要です。従って円滑な運用を行うためには、ステークホルダー間で守るべきルールや、脆弱性を管理する仕組み（人的・システム的）を構築する必要があります。
脆弱性管理についてCVSSによるスコアリングで対応している企業が多いと思いと思いますが、最近ではCVSSの代替手法として提案されたSSVC（STAKEHOLDER-SPECIFIC VULNERABILITY CATEGORIZATION）が注目されています。
ガバナンス
ガバナンスは、統治のあらゆるプロセスを意味します。
CCoEはクラウド利用のガバナンスを形成し、強化します。
AWSが提唱するガードレールの考え方を参考にしながら、Control Towerのガードレール機能を活用することで、クラウド利用のガバナンスを実現しています。
ガードレールの考え方については、前述した記事の「ガードレールの考え方」をご参照ください。
K
-
ガードレールの強化
- 2021年11月にアップデートされた「AWS Control Tower を使用して任意の AWS リージョンのサービスとオペレーションを拒否」を用いて、使用していない海外リージョンを封鎖、ルートユーザーの使用に関する操作を制限することで、クリティカルになり得るリスクを大幅に低減しました。
-
クラウド利用のガイドライン策定
- CCoE立ち上げ後、ある程度軌道に乗った段階でガイドラインの整備に取りかかりました。大規模な組織ではアーキテクチャに関わる内容をガイドライン化している例も見かけましたが、無理して真似る必要性はありません。やりやすいように組織の実態に合わせて、作り込むことで成功体験が得やすくなります。
P
-
クラウド利用の促進及び啓蒙
- ガイドラインは作成して周知した終わりではありません。AWSの各サービスは定期的にアップデートが行われて仕様が変わることは頻繁にあります。そのため、ガイドラインのアップデートは必須です。またガイドラインを利用する組織に対して、案内及び啓蒙をし続けることに終わりはありません。
T
-
新サービスなどのPoC及び共有
- 新しいAWSの機能についてCCoEがPoCなどを行ない、情報をまとめて共有することで、各組織の開発に寄与することができると考えています。最近ではカオスエンジニアリングなどのサービスも出てきていますが、全然キャッチアップができていないので、今後試していきたいと思っています。
「AWS Control Tower の包括的な制御管理の発表 (プレビュー版)」の通りに、Control Towerのガードレール機能が拡充されました。従来のガードレールのコントロールリスト（接頭辞「AWS-GR.」）に加えてフレームワーク・サービス・統制目標などのカテゴリでガードレールを整備することができます。
コスト最適化
予算内にコストを抑えることは必須で、コストが増えた場合は、リソースの妥当性及び必要性について評価し、必要によってコスト最適化を行なうのがクラウドを利用する際の責務だと考えています。
CCoEが機能したことで、結果的にアウトカムが出せた事例についていくつか紹介します。
K
-
異常検知
- CCoEで検出したコストの異常に関する情報を利用部門と共有することで、障害によって発生していたコスト急騰が確認でき、更なるコストの支出を防ぐことができました。
-
マネージドサービスのコスト最適化
- Control Tower導入時に生成されるCloudTrailの証跡が、元々利用していた分と重複していたことが発覚しました。重複したリソースを削除することで、コスト削減を実現しました。
- Security Hubの設定を見直すことで、コスト最適化を実現しました。デフォルトの場合
セキュリティ基準として「CIS AWS Foundations Benchmark v1.2.0」も有効化されます。使用していない場合は設定を見直しましょう。
-
Trusted AdvisorやCompute Optimizerの活用
- Trusted AdvisorやCompute Optimizerを活用したコスト削減を案内することで、コスト削減を実現しました。またこのような取り組みをガイドラインに落とし込むことで、自律的に活動できるような仕組み作りも継続しています。
P
-
本質的な評価がしにくい
- 前提としてコストの考え方が曖昧な場合は、ベースラインに対する妥当性が整理されていないため、無駄があっても予算内なら問題ないなど、利用部門で建設的でない思考が生まれやすくなります。
-
コスト関連のトラブル
- 開発プロセスにおけるテスト終了後のインスタンス停止忘れに伴い、本来発生しない大きい支出が発生しました。同じ過ちを繰り返さないように、ポストモーテムの重要性を感じました。またこの事象を踏まえてAWS コスト異常検出を活用しています。
T
-
プロセス改善
- コスト見積りをちゃんと行って、「何故、毎月このコストがかかるのか？」について説明できるように、プロセスを改善していきたいと思います。
コスト最適化は、リザーブドインスタンス (RI)や、Savings Plans（SP） の活用、EC2インスタンスのインスタンスファミリーの見直しなど色々なアプローチが存在します。
CCoEの活動（創意工夫）
普段CCoEとして個人だったりチームで工夫している点について、現在取り組んでいる施策を交えながら一部紹介します。
Security Hubの運用
Security Hubは、専用のセキュリティアカウントを作成した上で、指標とするセキュリティ基準を設定して運用しています。
会社全体のSecurity Hubで設定したセキュリティ基準のスコアは、セキュリティアカウントから確認できます。
しかし、Security Hubの現在の仕様では、セキュリティアカウントから各メンバーアカウントのスコアを把握することができません。
そのため、各メンバーアカウントからSecurity Hubのスコアを取得する際は、各メンバーアカウントに対してSSOを用いてアクセスを行いスクレイピングすることで、データを取得（※）しています。
また取得したデータは、BIツールを用いて可視化や分析を行い共有しています。
（※）「Prepare for consolidated controls view and consolidated control findings in AWS Security Hub」の通りに、2023年の第1四半期にSecurity Hubのアップデートが行われる模様です。注目すべきは、BatchGetControlEvaluationsというAPIが提供されることにより、Security Hubのスコアの取得が簡単になります。
数字目標は結果なので、結果を達成するための行動目標が設定できる組織であることが望ましいと思います。
例）Security Hubのセキュリティチェックで検出された項目について、いつまでに対応するなど
IAM Idenity Centerの運用
AWSの利用は、シングルサインオン（以下、SSO）によるサインインを基本としています。
AWSではSSOを使用するための仕組みとして、IAM Idenity Center4が用意されています。
AWS アカウントへのマルチアカウントアクセスやAWS アプリケーションへのシングルサインオンアクセスを可能とします。
Security Assertion Markup Language (SAML) 2.0を用いて他のIDプロバイダ（略称：IdP）に接続できるので、ユーザーは既存の認証情報でサインインできます。またユーザープロビジョニングを自動化するためのSystem for Cross-domain Identity Management (SCIM) もサポートしています。
CCoEではIAM Idenity Centerのユーザー及びグループを管理しています。
マルチアカウントを運用する中、定期的に棚卸しを行うためには、管理対象となるユーザー及びグループ、付随するパーミッションセット、グループに所属しているメンバー抽出など機械的に抽出する仕組みが必要です。
IAM Identity Center SCIM Implementationなどで提供されているAPIも利用していますが、ListUsersなどのAPIを使用する場合、本番環境の場合は取得するデータが多くなるため、APIの制約上一度のレスポンスで全ての情報を取得することはできません。
そのため、自動プロビジョニングを行なっている同期元となるIdPを操作するためのAPIや、AWSのSDKを用いて必要な情報を抽出及び取得するスクリプトを作成して棚卸しを自動化しています。
CDKの活用
共通基盤のアカウントで設定しているセキュリティやコストに関する監視の大部分は、CDKを用いて実現しています。
例えばコストの予算設定などもCDKを活用することで、煩雑になりがちな作業を楽にしています。
CDKの利便性は以前書いた「5分で理解するAWS CDK」をご参考にどうぞ。
マネジメントコンソールのカスタマイズ
マネジメントコンソール使用時、管理アカウントを識別するために、Chromeの拡張機能を自作しました。
管理アカウントは強力な権限を持っているので、Linuxでいうrootユーザーのような存在です。
マネジメントコンソールの装飾を変更して視認性を高めることで、管理アカウントの操作を気をつけるようにしています。
ダッシュボード開発
現在、モックの段階ですがAWSで提供されているSDK及びAPIを利用したダッシュボードを個人で開発しています。
用途としてセキュリティ・ガバナンス・コストに関する一部情報の可視化や、IAM Idenity Centerと自動プロビジョニングを行なっているIdPに対するユーザー管理など、CCoEの業務で必要となる要素を統合しています。
SPAで開発しているので、マネジメントコンソールに比べるとレンダリングが高速です。
おわりに
サッカーでいうミッドフィルダーのように、必要に応じて攻撃・守備を行いながら司令塔としてゴール（正しい方向）に導くことがCCoEには求められます。
こうゆう活動をしていると、泥臭いと表現する人がいますが私はそうは思いません。
重要なのは課題に対して、本質的な最適解を考えて施策を打ち続けることです。
以上です。
最後に宣伝
Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
是非ともよろしくお願いします。