Amazon Web Services ブログ

クラウドサービスの評価を最適化する方法

本投稿はワールドワイドで金融業界を担当しているプリンシパル・テクニカルプログラムマネージャーの Jennifer Code による寄稿を翻訳したものです。

私の同僚の Ilya Epshteyn が、 金融機関が機密性の高いデータのためにAWSサービスを承認する方法 というタイトルのブログでご紹介したように、金融業界では一般的にクラウドサービスの正式な評価プロセスが存在します。これらの評価プロセスは深さや幅に関しては様々ですが、いずれのプロセスも、業界の期待とテクノロジーリスク管理の健全性を確保しつつ、ビジネス要件を満たすのにはどのクラウドサービスが最適かを決定しようとするものです。このブログでは、クラウドサービスに対する新たな評価プロセスを構築する、または既存の評価プロセスを最適化する際に役立つシンプルなガイダンスを提供します。

私は、お客様と頻繁に会ってお客様のガバナンスとクラウドの評価プロセスについてディスカッションをしますが、その中でよく耳にするテーマがいくつかあります。１つ目は、評価プロセスが正式に存在する場合であっても、オーナー不在の場合が多く、結果としてそのプロセスが達成すべきビジネス上の成果を必ずしも理解しないまま、チームがプロセスに従っているという問題です。強いオーナーシップがなければ、参加者と評価範囲に一貫性が保てません。また、時には、構造化されたフレームワークではなく、個々の専門知識とベストエフォートに依存しているため機能性に差異が生じている場合もあります。最後に、お客様は、ほとんど例外なく、知識の共有を進めつつ、繰り返し学ぶことによって、評価プロセスの質を一気に向上させる方法があるのではと感じています。

正式なクラウドサービス評価プロセスがとても重要なのはなぜでしょうか?

金融サービス会社は、テクノロジーリスクの監視を証明するという、共通の規制上の義務を負っています。従来、企業のリスクフレームワークは、サイロ化された「3 つのラインによる防御」または (3LoD) で構成されていました。第一のラインはリスクの所有者としてコントロールを実行するビジネス / 運用担当者、第二のラインはリスクのモニタリングとコントロールの評価を行うリスク管理担当者、第三のラインは独立または内部監査人、またはリスクアシュランス担当者で構成されています。これらの 3LoD はそれぞれ、テクノロジーリスク、一般的な社内のポリシーの収集、ならびに他の防御ラインによって行われた一連の評価・監査に合わせて自チーム内で文書化された手順についての責任を負ってきました。

この既存の企業リスクフレームワークにクラウドの評価プロセスを組み込むことで、組織は重要な技術上の意思決定がどのように行われたかを適切に証明できるようになります。また、リスクがどのように評価され、軽減されるか、コントロール環境の強さがリスクアペタイトにどのように適合しているかといった点を、クラウドベースのサービスの微妙な差異に焦点を当てつつ説明できるようになります。

クラウド評価を最適化するためのヒント

金融サービスのお客様の期待を念頭に置き、お客様がクラウド評価プロセスを構築または改善するために実行できる3つのアクションを提案します。

  1. ガバナンス体制の正式化。ガバナンス体制が正式に確立されていない場合、金融サービス機関がとるべき最初のステップは、クラウドのガバナンスとコントロールに関してエンドツーエンドの責任を担うC-レベルの経営幹部を任命することです。
  2. プラットフォーム コントロールの優先順位付け。クラウド評価を策定する際に、優先順位と要件について、クラウド・プラットフォームとビジネス・アプリケーション機能の区分を取り入れます。セキュリティとレジリエンスのためのプラットフォームレベルのコントロールを最初の優先事項として重要視します。ビジネス・アプリケーションの機能に視点が移った時に、クラウドプラットフォームから継承されたコントロールに基づいて評価を調整できるようになります。
  3. 継続的な改善の組み込み。 知識共有と継続的な改善は、Day 1から明確に優先されるべきです。積極的な透明性があることにより、コントロールが構築され評価が行われる際に、3つの防御ラインすべてにわたっての信頼が築かれることが期待されます。意識的かつ積極的な共有によって、コントロールが設計されており、最初の本番ユースケースに対しても効率的に実行することができるという自信につながります。 AWSの使用量と専門知識が増えるにつれて、コントロールの強化と適用範囲の継続的な改善も容易になります。

ガバナンス体制の正式化

重要な最初のステップはクラウドのガバナンスに対する完全な説明責任を持つ適切な Cレベルの経営幹部を特定することです。この個人は、はじめにクラウドのガバナンスとコントロールのトーン設定を行い − クラウドの評価、使用状況、および継続的なモニタリングのための構造とプロセスを構築する責任をもちます。重要なのは、組織全体の専門知識を活用して、十分に制御されながらアジリティのある環境を確立するよう促す意欲のある、強力でポジションの高いリーダーを任命することです。

そのガバナンスのリーダーは任命され次第、評価プロセスを形成する機能横断的な構造、成文化されたポリシーと必要となるガバナンスプロセスを正式化し、現在進行中の評価のサポートをしなくてはなりません。私の経験では、正式なガバナンスの枠組みに支えられた多様な専門知識を活用できるバーチャルなチームが最も効果的です。

効果的なクラウドガバナンスの考慮事項

  • 効果的なクラウドガバナンスの目標を定め、専門知識を正当に評価する企業全体のクラウド戦略 は、導入と使用状況を測定しながら時間をかけて構築します。
  • クラウドガバナンスに責任のある経営幹部を任命、従事、およびコミットすることで全体的なガバナンス構造に統合し、継続的なモニタリングを行います。
  • 知識が豊富で 参加を約束できる（3 つの防御ラインにまたがった）リスクとコントロールのステークホルダーをクラウドのガバナンス活動における正式な参加者 にします。
  • 企業のガバナンス フレームワークとプロセスに準拠することで、クラウドイネーブルメントチームの存在を明確にします。
  • 定義されたプロセスを組織に伝達するとともに、承認されたクラウドサービスのみを利用していることを確実にする自動強制機能を使用します。

プラットフォーム コントロールの優先順位付け

私と顧客とのやり取りでよく見られたパターンは、クラウドサービスを評価するにあたり、たった１つのアプローチを作成し、それを全てのパターンに当てはめようとするやり方です。これは典型的に、各サービスを個別に評価する形式をとり、多くの場合、体系的に完成された詳細なチェックリストを伴います。

なぜこれが理想的ではないのでしょうか? 第一に、これは各サービスへの脅威は同等であることを前提としています（したがって、同じ評価が必要なコントロールを決定する適切な方法とされます）。第二に、このタイプのアプローチでは、評価者が能力または機能により区別することは認めていません（たとえば、データを中心としたサービスとコンピューティング サービスの違いを考慮しません）。最も重要な点は、既存の統制基盤を考慮していないことです（したがって、追加のコントロールの必要性を過大評価してしまう可能性があります）。

私が見てきた中で最も効果的だったのは、交渉不可能な基盤を確立した上で、環境、データの機密性、ビジネスの重要性など、他の要因に基づいて必要なコントロールを追加する、段階的なコントロール フレームワークです。この区分けによって、不適切なレベルのリスクを発生させることなく、実験を行うことができます。具体的には、すべてのデータタイプ、すべての環境において最初から予防的統制でなければならないコントロールもありますが、その他のコントロールではモニタリングをサポートすることによって、発見的統制から始めることが許容できるかもしれません。適切にコントロールされたイノベーションが目標です。

交渉不可能な統制基盤とはどのようなものですか ?
最上位のレベルでは、次のことが実施されていることを確認する必要があります。1) 社内のクラウドリソースがパブリックにアクセスできないこと、2) ユーザーが自身のロールに適した機能にのみアクセスできること、3) クラウド環境がレジリエントであること、4) 異常を特定して対処するために利用可能なモニタリングのツールセットがあること。この基盤があることにより、さらに安心して検証することができるようになります。

適切にコントロールされたクラウドプラットフォームが重視するのは：

強固な基盤があれば個々のサービスの評価を合理化できる

基盤となるクラウドプラットフォームをベースに、個々のクラウドサービスの評価は、サービスおよび予想される使用状況に合わせてパーソナライズできます。

Ilya の ブログ で紹介されているコントロールに関する考慮事項を補足させていただくと、個々のサービスに対して評価を行う際は、以下の点を確認してください。1) 機密データの暗号化が可能であること、できればお客様のマスターキー( AWS Key Management ServiceでのCustomer Master Key )を使用することが推奨されます。2) 「パブリック」アクセスが制限されていること （ほとんどの場合、VPC エンドポイントを利用して達成されます）。3) レジレリエンスとリカバリー能力が堅牢であること。4) 望ましい深さと幅についての 設定のモニタリング  (通常は AWS Config とのサービス統合によって達成されます)。

この基本的な確認は、クラウドプラットフォームが実験のために適切なコントロールを提供しているかどうかを知らせるのに役立ちます。これにより、 予防的なアクセスポリシー を 定義しながら、組織は貴重な経験を積むことも可能になります。また、暗号化の強制、新しいサービスが含まれるように更新された監視モニタリング 、および異常に対処するために設計された 修正の自動化も設定します。

このパラレルなアプローチにより、一般的なユースケースをキャプチャして共同作業を行い、パイプラインに統合するためのアーキテクチャと構成パターンを定義し、ビジネスユースケースを理解して、コントロールの範囲を検証するといった事を、本番環境で使用するずっと前に行うことができます。

継続的な改善を組み込む

最後の、かつ最も重要な要素は、クラウドガバナンスのあらゆる面で継続的な改善を組み込むことです。頻繁なコラボレーション、コントロールの重要な評価、インシデントや異常に対する迅速な根本原因分析により、信頼が促進されます。信頼が形成されると、ガバナンス、開発、運用における俊敏性が促進されます。

部門間のコラボレーションが頻繁に行われると、以下のことが促進されます:

  • 開発のパイプラインにコントロールを統合したシフトレフト。これにより、エンジニアは開発中に潜在的なコントロールの問題に対処することができ、本番デプロイ前にセキュリティとコンプライアンスの検証を確実に完了できます。
  • 本番運用の自動化が進み、監視機能が強化されることで、レジリエンスと災害復旧のテストがより頻繁に実施できるようになります。これにより、予期せぬ本番環境の問題に耐えられるという安心感を得ることができます。
  • コントロールの設計と運用効率の両方について、コントロール環境のプロアクティブなレビューと評価を行うための社内リスク部門と監査部門による積極的な連携。
  • AWS Well-Architected フレームワーク を活用することで、環境の安全性、回復性、パフォーマンスの高さ、コストの最適化について継続的な検証を行う。

まとめ

上記の活動により、3つの防御ラインすべてを横断するコラボレーション環境を構築し、クラウドコンピューティングの破壊的な効果を利用するためのアジリティの文化を取り入れることができると確信しています。

私のお勧めは、最後のヒントから始めて、学んだ教訓や情報共有のためのコミュニケーションを正式なものとすることです。オープンで率直な現状評価から始めることで、組織全体の信頼が構築され、継続的な改善のための重要な基盤が確立することができます。

これらのヒントが、お客様のクラウド評価のアプローチを最適化し、リスク部門と監査部門の関与を高め、ひいてはクラウド ガバナンスの全体的な強化に役立ったかどうか、ご意見を頂ければ幸いです。

適切な統制ができますように！

著者について

Jennifer は、AWS のプリンシパル・テクニカルプログラムマネージャーです。最も機密性の高いワークロードを管理および統制する金融サービス組織をサポートしています。料理や旅行が大好きで、常にキッチンや世界中の新しい体験を探求しています。

jencode@amazon.com
http://aws.amazon.com/financial-services/

 

翻訳はソリューションアーキテクトの渡邉 浩一郎が担当しました。原文はこちらです。