はじめに
ガバメントクラウドを知っていますか?
直訳すると「政府クラウド」という名前から、
ガチガチ鉄壁感と分厚いガイドラインの気配を私は感じます。
ただ、実態は「お、どこかで聞いたベストプラクティス」といった感じに、
仕上がっていることを知りました。
今回は↓の5/29開催の勉強会に参加するにあたって、
ガバメントクラウドに対する基本知識のおさらいをする記事となります。
ガバメントクラウドとは?
デジタル庁のホームページから抜粋すると以下説明が記載されていました。
政府共通のクラウドサービスの利用環境です。クラウドサービスの利点を最大限に活用することで、迅速、柔軟、かつセキュアでコスト効率の高いシステムを構築可能とし、利用者にとって利便性の高いサービスをいち早く提供し改善していくことを目指します。
要は「危険な操作を防ぐ/発見できるルールが整備されたセキュアなAWS環境とモダン構成を迅速に開発できるテンプレ一ト」などの一式を連携してもらえるイメージ。
また、ガバメントクラウドはクラウドスマート(クラウドを賢く利用する)を目的としており、
スマートとはモダン技術(主にマネージドサービス/IaC)を指すとのこと。
ガバメントクラウドの目的とは?
ガバメントクラウドを展開する目的としては大きく2点が存在している。
ガバメントクラウドの目的
- セキュリティ
- その水準を一括で管理/統制することで全てのシステムのセキュリティレベルの一定以上に引き上げることを目的
- コスト削減
- マネージドサービス、IaC、CI/CDを通して、開発スピード向上とインフラ管理構築⼯数削減、継続的改善の効果を得る
※⾃治体がガバメントクラウド利⽤に向けておさえておきたい 10 のことより抜粋
以下私見ですが、
上記目的の背景としてセキュリティについては、
これまで各自治体や官庁が設計/管理していたためセキュリティ水準に、
バラつきがあったため水準引き上げようとしている背景があると思っています。
また、コストについても、サーバ管理をそれぞれ地方で行っていると想定。
環境提供を一元化することで、リザーブドインスタンスの恩恵や、
伸縮性のあるクラウドの拡張性を持つサーバ適正利用と部分的な管理業務を一括化しようとしているのではないかと思います。
ガバメントクラウドの仕組みは?
具体的な利用としては、申請を出せば政府管理AWSアカウントから、
ControlTower経由でアカウントを発行してくれる。
また、システム利用者側が構築に必要なIaCテンプレートや参考資料も連携してくれる。
ガバメントクラウドの仕組みは主に以下3つで構成されている
①アカウント払いだし
- メインアカウント(デジタル庁)からControlTowerとOrganizationを利用して、組織を作成
- ControlTowerはServiceCatalogと連携して利用者向けアカウント(利用者向け)を生成
- SSOユーザを利用して利用者向けアカウントにアクセスが可能となる
ガバメントクラウドで考える技術的統制と効率性〜AWSでの実現策〜より抜粋
※一般的なControl Towerの使い方例
ガバメントクラウドで考える技術的統制と効率性〜AWSでの実現策〜より抜粋
②セキュリティ設計
前提としてガバメントクラウドのセキュリティは「予防的統制」「発見的統制」を主として検討している。
以下「予防的統制」「発見的統制」の説明と実装に利用するAWSサービスを記載
予防的統制:危険性の高い操作を事前に防止
- 実装方法:
- AWS OrganizationのSCP
- 予防的統制の具体的な設定例
- ガバメントクラウドでの設定/監査ログの削除アクション
- リージョン制限
- アクセスキーの作成やセキュリティ統制が困難なサービス利用禁止
- MFA有効化
発見的統制:リソースが不正な状態か監視/通知
- 実装方法:
- AWS Config
- AWS TrustedAdvisor
- AWS SecurityHub
- Amazon GuardDuty
- Amazon CloudTrail
- Amazon CloudwatchLogs/Alarm
- 発見的統制の具体的な設定例
- AWSサービスが提供するセキュリティサービス設定内容(GuardDuty/Securityhub)をリスト化して必要項目をAWSサービスを持ちいて有効化する。
- 発見的統制の展開方法
- 「GuradDuty」「Securityhub」を監査用アカウントから全てのアカウントに展開することでガバナンスを設けている
ガバメントクラウドで考える技術的統制と効率性〜AWSでの実現策〜より抜粋
- 「GuradDuty」「Securityhub」を監査用アカウントから全てのアカウントに展開することでガバナンスを設けている
また、利用者向けアカウントから各サービスの実行履歴やサービス設定内容ログは監査用アカウント(デジタル庁)に集約される
ガバメントクラウドで考える技術的統制と効率性〜AWSでの実現策〜より抜粋
③IaCテンプレートの活用
提供されるテンプレートは3種類存在している
- 環境自動適用テンプレート
- 統制側(デジタル庁)がアカウント払い出し時に実行するテンプレート
- 必須の設定が盛り込まれているため利用者側から操作不可
- 統制側(デジタル庁)がアカウント払い出し時に実行するテンプレート
- ガバナンスベースのテンプレート
- CDKの実装を利用システム側へ提供し、初回に必ず実行
- 環境自動適用テンプレートと同様利用者側から操作不可
- CDKの実装を利用システム側へ提供し、初回に必ず実行
- サンプルテンプレート
ガバメントクラウド利用の注意点
注意したいのが、ガバメントクラウドはあくまでアカウントや各システムが共通的に利用する利用する技術ガバナンスを用意するため、
システムごとの信頼性やセキュリティ検討は各システムで必要になる。
※インフラ面は全てガバメントクラウドが管理してくれるわけではない。
※⾃治体がガバメントクラウド利⽤に向けておさえておきたい 10 のことより抜粋
ガバメントクラウド利用者のメリットは?
「ガバメントクラウドの目的」に対し、
利用者目線では以下のようなメリットが存在すると考える。
メリットは複数存在していたが、いくつかピックアップして記載。
セキュリティ
ガバメントクラウドの方針に沿うことで利⽤開始時からセキュリティ基準が⾼く、
セキュアなシステムリリースを行える。
開発
IaCテンプレートの提供が受けられるため、開発が迅速に行える。
特別な要件が無い限りはサンプルテンプレートの一部修正で構築が行える。
コスト
従来自身で発注/管理していた環境をクラウド上で管理される。
また、フルマネージドサービスの活用により運用コストが削減される。
ガバメントクラウドのデメリットは?
逆にデメリットを考えてみると以下が挙げられると考えている。
以下デメリットに小規模な地方自治体が対応できるとは考えにくいため、
比較的中~大規模向けを想定しているのかもしれない。
①ガイドに沿った開発ができる要員の確保
ガバメントクラウドはモダン構成を実現するための、
クラウドを環境を提案することを目的としている。
新規構築案件であれば本ガイドに沿えることを条件として依頼先/IT要員の確保を行えそうだが、サーバ保守/サポート切れに伴う強制イベントでは学習時間の確保ができず対応できる要員確保を行えない可能性がありそう。
②保守運用要員の確保
ガバクラの構成(フルマネージドサービス/サーバレス/IaC)に沿うと保守運用工数が減ると思う反面、ある程度IaCや各種AWSサービスに精通している保守要員が必要となる。
既存保守担当者向けの学習時間の確保や問題発生時の運用手順作成が行えず、想定外の工数が発生しそう。
③定期的な改善運用
システムリリース後は「定期的な改善運用」を推奨しているため、
適宜運用工数が必要となる。
結局は重要度が高いイベント以外はスルーして結局形骸化しそう。
キーワード抜粋
BLEA
「BLEA」=「Baseline Environment on AWS」
AWSが提供しているCDKのサンプルテンプレート。
目的としては一定水準を満たすセキュリティの自動設定
AWS Security Hubにおける特定ルールセットの「すぐに対処が必要 (CRITICAL) 」「優先して対処が必要 (HIGH) 」が検出されないような設定が入っている。
SIEM
「SIEM」=「Security Information and Event Management」
多様なセキュリティログを収集し一元的に管理・分析行うことを指す。
AWSで実現する場合は「Amazon OpensearchService」を中心として、
各監視/監査サービスを組み合わせて実現することができる。
AWS側でも、SIEM on Amazon OpenSearch Serviceという、Amazon OpenSearch Serviceの環境にSIEMとして必要な機能を実装したOSSをAWSが提供している。
SIEMのイメージとしては、以下図の通りであり、
多種多様なセキュリティログやイベントを集約してOpenserchに集約する。
※siem-on-amazon-opensearch-serviceより抜粋
SIEM on Amazon OpenSearch Serviceについては以下参照
さいごに
ガバメントクラウドに関する情報をまとめてみました。
本記事が同様の勉強会に参加される人の助けになれば幸いです。
参考