ガバメントクラウドの道案内『統合運用管理補助者編』

ガバメントクラウドに関する情報は AWS も含めてさまざまな方面から毎日のように発信されており、どの情報を追ったらいいのか、何を気にするべきなのかわからなくなってくることもあるかと思います。

そこで、このブログでは「ガバメントクラウドの道案内」と題して自治体ガバメントクラウドに携わる方がそれぞれ何を検討すべきで、どの資料を確認した方がいいのかを役割別にまとめています。

本ブログは統合的に環境の統制をするベンダーの方へ向けた「統合運用管理補助者編」です。
そのほかの方に向けたブログに関しては以下リンクをご参照ください。

ガバメントクラウドの道案内:『自治体職員編』
ガバメントクラウドの道案内:『統合運用管理補助者編』（本ブログ）
ガバメントクラウドの道案内:『ネットワーク構築運用補助者編』
ガバメントクラウドの道案内:『ASP＆運用管理補助者編』

自治体のお客様において、現在ガバメントクラウドの利用検討が進んでいます。ガバメントクラウドを利用するうえでは、さまざまな事業者が分担して作業することが多いです。

例えば、「ネットワーク構築運用補助者」がネットワーク経路を整備し、「運用管理補助者」が運用管理を行う個別領域の上に、「ASP」がシステムを構築します。それぞれの事業者の詳細な役割分担については、こちらのブログをご参照ください。

単独利用方式の ASP が複数ある場合に、統合的に環境の統制をする体制を取るケースがあります。そのような場合、個別領域の運用管理補助者とは別に統合運用管理補助者を立てて、統合運用管理補助者がすべての AWS アカウントの統合管理を行います。

このブログでは、統合運用管理補助者が運用管理を行っていく上で気にするべき点や、参照できる資料をまとめました。作業内容の確認などに使っていただけるとうれしいです。

以下のような方を対象として記述しています。

統合運用管理補助者を担う事業者の方
統合運用管理補助者を立てることをご検討されており、詳細を知りたい自治体の方

以下の章で構成されています。

統合運用管理補助者が必要になる場合と担当する事業者について
統合運用管理補助者の役割範囲
マルチアカウントの場合の情報の集約方法
アラートが上がったときの対応について
まとめ
免責事項
ガバメントクラウドに関するお問い合わせ

統合運用管理補助者が必要になる場合と担当する事業者について

統合運用管理補助者は、基本的には単独利用方式のアプリケーションが存在し、その上で自治体様に統合運用管理をしたいという意志がある場合に設置されます。全業務のアプリケーションが共同利用方式のみで完結する場合は不要になることが多いと思われます。

また、ネットワーク構築運用補助者がガバメントクラウド全体の運用管理補助業務を担える場合、ネットワーク構築運用補助者が統合運用管理補助業務を兼任することが想定されています。これは、ネットワーク構築運用補助者はもともとガバメントクラウド全体のネットワークを管理することが求められているため、セキュリティについての管理も兼任しやすいからです。

そうでない場合は、いずれかの単独利用運用管理補助者が統合運用管理補助者としてガバメントクラウド全体の運用管理補助業務を担当します。

統合運用管理補助者の役割範囲

統合運用管理補助者の役割範囲は主にインフラストラクチャレイヤーのセキュリティ面での運用管理を行うことです。あくまで参考ですが、例として以下のような業務が存在します。

ガバメントクラウド必須適用テンプレートなどの適用
AWS Config の構成情報を集約して監視、構成管理を行う
AWS CloudTrail のログを集約して監視
Amazon Inspector, AWS Security Hub, Amazon GuardDuty などのセキュリティサービスの情報を集約して監視
以上のサービスで不審な動きが確認されたりアラートが発報された場合の対応
必要に応じて、情報が集約されたダッシュボードの作成
必要に応じて、運用管理補助者兼 ASP 事業者へのガバメントクラウドの使い方の研修や、自治体との情報連携など

Amazon CloudWatch などで確認できるアプリケーションレイヤーでのログやアラートの監視は、個々の運用管理補助者が行うことを想定しています。

マルチアカウントの場合の情報の集約方法

複数の AWS アカウントのセキュリティサービスなどの情報を集約するには、 AWS Organizations の機能を使うことが一般的です。しかし、ガバメントクラウドの個別領域はデジタル庁所有の AWS Organizations のメンバーアカウントなので、複数の個別領域の情報を集約するために AWS Organizations の機能を個別に適用できません。複数のアカウントの状況を把握するために、いちいち個別のアカウントから確認するのは大変です。

そのため、AWS Organizations の機能に頼らず情報を集約することが必要です。主に 2 とおりの方法が考えられます。

それぞれのサービスで設定し、個別のサービスにおいて結果を集約する
さまざまなサービスの結果を Amazon Simple Storage Service (Amazon S3) にエクスポートし、SIEM on Amazon OpenSearch Service (SIEM on AWS) を利用する

(1) それぞれのサービスにおいて設定する場合
統合管理したいアカウント数が比較的少ない場合、または Amazon OpenSearch Service の費用など SIEM on AWS の利用に必要な費用や実装・運用コストを払いたくない場合は、それぞれのサービスにおいて個別に設定することで AWS の機能を用いて情報を集約できます。

AWS Config では、Config Aggregator を用いることで AWS Organizations に制約を受けず情報を集約可能です。詳しくは、ドキュメントをご参照ください。
AWS CloudTrail では、Amazon CloudWatch に証跡を送信でき、Amazon CloudWatch Cross Account Observabillity を有効にすることで集約元のすべての CloudWatch ログを集約先アカウントから見られるようになります。詳しくは、ドキュメントをご参照ください。
Amazon Inspector においては、上記のような自動集約機能がないため、Amazon S3 エクスポート機能を定期的にトリガーするなどして情報を集約する必要があります。詳しくは、ドキュメントをご参照ください。
AWS Security Hub においては、こちらの CloudFormation テンプレートなどを用いて結果を Amazon S3 に保存し、それをアカウント間でコピーして情報を集約する必要があります。
Amazon GuardDuty においては、個別に招待することで複数アカウントの検出結果を集約できます。詳しくは、ドキュメントをご参照ください。
Amazon Detective では、メンバーアカウントを追加することで Organizations に制約を受けず情報を集約可能です。詳しくは、ドキュメントをご参照ください。

詳しくは、2023 年 12 月 13 日に開催されたウェビナーでもご紹介いたしました。その際の資料や動画はこちらにございますので、ぜひご確認ください。

(2) SIEM on AWS を利用する場合
統合管理したいアカウント数が比較的多く、Amazon OpenSearch Service の費用などを払うことができ、AWS Cloud Development Kit (AWS CDK) でのデプロイに親しみがある場合、SIEM on Amazon OpenSearch Service (SIEM on AWS) を活用することが考えられます。

SIEM on AWS は、セキュリティインシデントを調査するためのソリューションです。Amazon OpenSearch Service を活用して、AWS のマルチアカウント環境下で、複数種類のログを収集し、ログの相関分析や可視化できます。デプロイは、AWS CloudFormation または AWS CDK で行い、30 分程度でデプロイは終わります。AWS サービスのログを Amazon S3 のバケットに PUT すると、自動的に ETL 処理を行い、SIEM に取り込まれます。ログを取り込んだ後は、ダッシュボードによる可視化や、複数ログの相関分析ができるようになります。

各アカウントのセキュリティサービスから Amazon S3 のバケットに PUT する方法も SIEM on AWS のドキュメントに記載してありますので、ご参照ください。

アラートが上がったときの対応について

統合運用管理補助者が確認すべきアラートとして、以下のようなものがあります。

セキュリティインシデントのアラート (AWS Security Hub, Amazon GuardDuty など)
AWS サービス障害情報のアラート (AWS Personal Health Dashboard など)

一方で、ASP/運用管理補助者が確認すべきアラートとして、以下のようなものがあります。

AWS サービスの CloudWatch メトリクスに関するアラート (CPU 使用率等)
アプリケーションのログにひもづくアラート (CloudWatch Logs で確認できるもの)

アラートが上がった場合に行う作業の例として、以下のようなものがあります。

原因調査などを実施する
各個別領域の運用管理補助者や ASP と協力し、解決する
必要に応じて自治体に情報連携する

原因調査には、AWS のサービスを利用できます。
Amazon GuardDuty と AWS Security Hub については、「Amazon GuardDuty と AWS Security Hub 利用時のオペレーションガイド」をこちらからダウンロードできます (3 つの資料が連結されており、一番下の資料です) 。
Amazon CloudWatch については、こちらから初心者向けのハンズオンを体験できます。併せてご覧ください。

障害の発生時に行う作業の例として、以下のようなものがあります。

すみやかに自治体に障害発生状況や復旧の状況などを通知する
原因調査などを実施する
各個別領域の運用管理補助者や ASP と協力し、解決する
必要に応じて、 CSP に連絡する

まとめ

このブログでは統合運用管理補助者となる事業者様向けに統合運用管理補助者の役割範囲や作業内容についてご説明いたしました。ガバメントクラウドではガバメントクラウド固有の事情や制約などが発生し、初めて触れる事業者様には難しいものとなっているかと思います。そんな中、統合運用管理補助者の作業内容を理解し、複数のガバメントクラウド個別領域全体を安全に運用管理していくためにこのブログをお役立ていただけると大変うれしく思います。

免責事項

本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。
本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。
本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。
本ブログや添付資料の利用によって生じた損害などの責任は利用者が負うものとし、アマゾンウェブサービスジャパンは一切の責任を負いかねますことご了承ください。

上記ご了承のうえ、ご利用ください。

ガバメントクラウドに関するお問い合わせ

AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。
本記事で紹介したタスクリストに関するお問い合わせの他、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。
https://thinkwithwp.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

Amazon Web Services ブログ