前回は、AWSのガバナンス周りのアーキテクチャを見てきました。今回は、セキュリティ周りを見ていきたいと思います。
教材は前回と同様で「ガバメントクラウド利用における推奨構成（AWS編）.pdf」を見ていきいます。
セキュリティ構成①
セキュリティの推奨構成は以下の通りです。パット見たところ、ファイアーウォールと鍵管理、脆弱性検査に関するアーキテクチャのようです。
引用元：ガバメントクラウド利用における推奨構成（AWS編）.pdf（デジタル庁）P.24
| アイコン | 名称 | 機能 |
|---|---|---|
 |
Transit-Gateway | VPC間を中継するL3スイッチ(ルーター)のようなもの。通常、複数のVPCを相互につなぐ場合、すべての組み合わせの2VPC間の設定が必要だが、本機能であればTransit GatewayにつなぐだけでVPCは相互に通信可能になる。 |
 |
VPC_NAT-Gateway | プライベートサブネットからインターネットへの一方通行の出口を作る機能。外部からの不要な接続を遮断しつつ、パッチ取得などの外向き通信を可能にする。 |
 |
Network-Firewall_Endpoints | いわゆるファイアウォール。VPCエンドポイントが「特定サービスへの専用出口」であるのに対し、こちらは「外部（ネットや他VPC）へ向かう通路の途中に置く検問所」。通過するパケットを検査（フィルタリング、IDS/IPS）し、通して良いか判断する機能を持つ。 |
 |
VPC_Network-Access-Control-List | VPC内のサブネット単位で動作するファイアウォール機能。Network Firewallよりも簡易的な機能だが、無料で利用できる点がメリット |
 |
VPC_Flow-Logs | L3パケットの送信元、送信先等のメタデータを取得するログ。いわゆるFirewallログ。Network Firewallは経路上に設定するが、Flow Logsは経路上には設定せず監視対象のリソースに設置する。あくまでメタデータのみ保持し、パケット全体は保持しない |
 |
Systems-Manager_Patch-Manager | Windows、Linux、macOS等、OSのパッチを管理するシステム。windowsのWSUSサーバーのようなもの |
 |
Inspector | EC2等の脆弱性検査ツール。パッケージの脆弱性、ポート設定の脆弱性などを構成ベースで検査する。（最近、Lambdaについてはコード脆弱性を静的に解析できるようになった） |
 |
Key-Management-Service | RSAなどの鍵の生成、ローテーション、削除などを管理する機能。S3の暗号化鍵などを保管したりする |
 |
Certificate-Manager | SSL/TLS証明書を発行・管理する機能。似た機能のKey Management Serviceは鍵情報のみを保持しており、Certificate Managerは証明書を管理することが違い（証明書用の鍵情報はCertification Manager内に保持しており、KMSでは保持していない） |
 |
Detective | セキュリティインシデントの原因調査や分析を行う機能。Security Hubが情報の一元管理に主軸を置くのに対して、Detectiveでは時系列の根本原因分析に主軸を置く |
 |
Secrets-Manager | パスワード管理ツール。Key Management Managerはデータ自体の暗号化/復号化に使う鍵を管理するのに対して、Secrets ManagerではパスワードやAPIキー、アクセストークンなどの認証・認可のための鍵を管理する |
本番環境のインターネット通信
構成の中で特に気になったのが、インターネットへの通路です。感覚的には、本番アカウント内にPublic SubnetやNat Gateway、Internet Gatewayを設置するものと思っていたのですが、どうやら全てのインターネット通信は運用管理アカウント経由で出ていくようです。
よく考えてみると、これまでの記事にてメインの利用ユーザーは閉域網からのアクセスとなる事が前提となっているためインターネット通信は基本発生しません。このインターネット通信はあくまでメンテナンス用途（パッチ適用）等のみで利用する事が、教材P.82「4-3.ガバメントクラウドにおけるインターネット接続」に記載されています。
※ Patch Managerはパッチ適用の可否を指示するのみで、実際のパッチダウンロードはこのNat Gateway経由で各OSが行う必要があるようです。
この構成になっている理由を推測すると、責任分界点としてパッチ適用はアプリケーション内部の話であり、事業者にて管理するものであると定義しているのだと思います。ガバメントクラウド管理側（デジタル庁）では、パッチ適用までは面倒見ないけど、脆弱性がないかは基盤として確認しておくよという立ち位置のように見えます。
セキュリティ構成②
上記でセキュリティ構成は終わりと思っていたのですが、セキュリティについてはCI/CDを用いたアプリケーションコードの脆弱性検査が別図として掲載されていたので、こちらも見ていきます。こちらは、特に気になる点もないので、利用するサービスの概要だけ確認していきます。
引用元：ガバメントクラウド利用における推奨構成（AWS編）.pdf（デジタル庁）P.26
| アイコン | 名称 | 機能 |
|---|---|---|
 |
CodePipeline | CI/CD（継続的インテグレーション/継続的デリバリー）サービス。CodeCommitへの変更を検知し、自動でパイプライン処理を実行する |
 |
CodeCommit | フルマネージドのGitリポジトリ |
 |
CodeBuild | ビルド・テストを自動化するエンジン。CodePipelineの内部で呼ばれる |
 |
CodeGuru | コードレビューツール。静的解析を行う「CodeGuru Security/Reviewer」と、動的解析を行う「CodeGuru Profiler」を内包する。Java、Pythonには対応している |
 |
Elastic-Container-Service | いわゆるコンテナオーケストレーションサービス。Dockerコンテナの実行、スケーリングなどを管理する |
 |
Elastic-Container-Registry | コンテナレジストリサービス。Dockerコンテナの定義を保存している |
 |
Fargate | サーバーレスコンテナエンジン。ECS+EC2ではEC2のOS管理を自ら実施する必要があるが、ECS+Fargateでは不要 |
参考資料
ページ中で利用しているAWSアイコンは、以下のページからダウンロードしたものを利用しています。
