Security Agentについて
Security Agentは以下のような3つの機能があり、それぞれプレビュー版で利用することができます。
| 機能 | 概要 |
|---|---|
| デザインセキュリティレビュー | 設計ドキュメントを入力として、構成・前提条件・設計判断を踏まえたセキュリティ観点のレビューを実施 |
| コードセキュリティレビュー | GitHub上のPull Requestを対象に、実装内容に対するセキュリティ観点のチェックや指摘を実施 |
| オンデマンドペネトレーションテスト | AI による自動ペネトレーションテストをオンデマンドで実行し、設計や実装に起因する脆弱性の兆候を検出 |
ここでは、デザインセキュリティレビューを検証し、実際にどのようなレビュー結果が得られるか、ハンズオン形式でご紹介します。
Security Agentの設計レビュー検証
このハンズオンでは「設計書を読ませるだけで、どこまで実践的なレビューが得られるか」を確認します。
1. 設計レビュー対象の準備
レビュー対象には、設計途中の一次評価を想定し、以下のようなシンプルな構成を用意しました。
システム概要
- 社内外ユーザーがファイルをアップロードおよびダウンロードできるシンプルなWebアプリケーションを想定する
- AWS上にEC2 1台構成で構築し、インターネットからのアクセスを前提とする
以下のようにあえて典型的なNG設計を含め、Security Agentのレビュー能力を確認してみます。
・EC2単体構成 ・インターネットから直接アクセス可能 ・SSHを0.0.0.0/0で許可 ・Web機能に認証なし ・HTTP通信のみ（TLSなし） ・EC2にAdministratorAccessを付与 ・集中ログ管理の方式がは未定義 ・監査ログ（CloudTrail 等）の利用方針は設計書上で明示しない
レビュー依頼した設計書の全容は以下です。
公開ファイル共有Webシステム設計書（レビュー対象） 1.システム概要 本システムは、社内外ユーザーがファイルをアップロードおよびダウンロードできる シンプルなWebアプリケーションを提供する。 AWS上にEC21台構成で構築し、インターネットからのアクセスを前提とする。 2.アーキテクチャ [インターネット]→[EC2（Webサーバー+アプリケーション）]→[EBS（ファイル保存）] 2.1使用サービス ・AmazonEC2：Webサーバー兼アプリケーションサーバー ・AmazonEBS：アップロードファイルの保存 ・SecurityGroup：ネットワーク制御 3.インフラ構成 3.1ネットワーク ・単一VPCを使用する ・パブリックサブネットを1つ使用する ・EC2にはパブリックIPを付与し、インターネットから直接アクセス可能とする 3.2セキュリティグループ（インバウンド） ・TCP/22（SSH）：0.0.0.0/0からの通信を許可 ・TCP/80（HTTP）：0.0.0.0/0からの通信を許可 ・TCP/443（HTTPS）：設定しない 3.3セキュリティグループ（アウトバウンド） ・すべてのアウトバウンド通信を許可 4.認証・認可設計 4.1Webアプリケーションの認証 ・ユーザー認証機能は実装しない ・アップロードおよびダウンロードは誰でも実行可能とする 4.2管理者操作 ・管理者はSSHを使用してEC2にログインし、サーバー上のファイルを直接操作する 5.データ保護設計 5.1保存データ ・アップロードされたファイルをEBS上に保存する 5.2暗号化 ・EBS暗号化の設定は設計上明示しない ・通信はHTTPSを使用せず、HTTPのみを利用する 5.3ファイル公開方式 ・ダウンロードURLは連番形式を想定する （例：/files/1のような形式） 6.IAM設計 6.1EC2インスタンスロール ・EC2にIAMロールを付与する ・IAMロールにはAdministratorAccessポリシーを付与する 7.ログおよび監査設計 7.1ログ ・アプリケーションログはEC2のローカルディスクに出力する ・集中ログ管理は未定義 7.2監査 ・CloudTrailの利用については本設計書では明示しない ・セキュリティアラートは設定しない
2. Security Agentのセットアップ
設計レビューを実行する前に、まずSecurity Agentを利用できる状態にする必要があります。
1. AWSマネジメントコンソールにログイン
2. サービス検索でSecurity Agentを選択
3. 利用するAgentSpaceを作成または選択する
3. 設計書レビューを依頼する
テキストファイル形式の設計書をアップロードし、Agentにレビューを依頼します。
ファイルの形式としてはDOC、DOCX、JPEG、MD、PDF、PNG、TXTがアップロード可能です。
4. レビュー結果を確認する
数分待つと、以下のような結果がまとめてみられます。
各項目を押下すると具体的な指摘内容や、改善案を確認することができます。
例として、Secure by Default Best Practicesの項目の指摘内容を見てみます。
日本語にすると以下のような指摘内容となり、この項目だけでも、典型的なNG項目のいくつかが指摘されていることがわかり、改善案まで記載されています。
Findings:SecurebyDefaultBestPractices（安全なデフォルト設定のベストプラクティス） ComplianceStatus Non-compliant（非準拠） SecurityRequirementDescription SecurebyDefaultBestPractices （安全なデフォルト設定のベストプラクティス） Comment 本項目が非準拠（Non-compliant）と判定された理由は、 本システムが複数のコンポーネントにおいて安全でないデフォルト設定を使用しているためです。 具体的には、以下の点が確認されています。 * SSHアクセスが0.0.0.0/0に対して開放されている * IAMポリシーとしてAdministratorAccessが付与されている * EBSボリュームの暗号化が設定されていない * CloudTrailが有効化されていない これらの設定により、 インターネットからの不正アクセスや、 権限昇格によるリスクが不必要に高い状態となっています。 RemediationGuidance （改善・是正ガイダンス） 準拠状態を達成するために、以下の対応が推奨されます。 * SSHアクセスを特定の信頼されたIP範囲のみに制限する * AdministratorAccessを最小権限のIAMポリシーに置き換える * EBS暗号化をデフォルトで有効化する * CloudTrailを有効化し、操作ログを取得・管理する
全項目の評価については、以下のようになりました。
| セキュリティ要件 | 判定 |
|---|---|
| Trusted Cryptography Best Practices （暗号技術のベストプラクティス） | Insufficient data （判断に必要な情報が不足） |
| Audit Logging Best Practices （監査ログのベストプラクティス） | Non-compliant （非準拠） |
| Authorization Best Practices （認可のベストプラクティス） | Non-compliant （非準拠） |
| Secure by Default Best Practices （安全なデフォルト設定のベストプラクティス） | Non-compliant （非準拠） |
| Authentication Best Practices （認証のベストプラクティス） | Non-compliant （非準拠） |
| Privileged Access Best Practices （特権アクセス管理のベストプラクティス） | Non-compliant （非準拠） |
| Information Protection Best Practices （情報保護のベストプラクティス） | Non-compliant （非準拠） |
| Secret Protection Best Practices （シークレット保護のベストプラクティス） | Non-compliant （非準拠） |
| Tenant Isolation Best Practices （テナント分離のベストプラクティス） | Not applicable （評価対象外） |
| Log Protection Best Practices （ログ保護のベストプラクティス） | Not applicable （評価対象外） |
Non-compliantとなった項目を確認すると設計上致命的になりやすい領域を拾っていることがわかります。
-
Authentication/Authorization ー 認証・認可が存在しない設計を正しく検知
-
PrivilegedAccess ー EC2にAdministratorAccessが付与されている点を問題視
-
SecurebyDefault ー 初期状態のまま使うと即リスクになる設計であることを指摘
-
AuditLogging ー 管理操作が可能なのに監査ログ設計がない点を指摘
-
Secret/InformationProtection ー SSH鍵やファイルの保護が設計上考慮されていない点を検出
なお、一般的なアーキテクチャ設計の観点では、「インターネット公開部分に ELB を配置し、EC2はプライベートサブネットに置く」といった構成が推奨されるケースも多くあります。
しかし、本検証では「EC2を直接インターネットに公開する設計そのものが妥当か」といった大局的な構成是非までは踏み込まず、与えられた設計前提の中でのリスク評価に重点を置いた指摘が中心となっています。
これはSecurity Agent の「設計書に記載された前提・構成を正として、その中でのリスクを評価する」という性質によるものと考えられます。
この点は、人間によるアーキテクチャレビューと併用する前提で使うべきポイントと言えるのではないでしょうか。
また、以下の項目に関してはNot applicable（評価対象外）の項目としており、システムの前提条件（単一テナント構成、ログ設計の有無など）を反映したうえで、評価対象外となる要件をNot applicableとして正しく除外していることがわかります。
- TenantIsolation ー マルチテナント構成ではない
単一インスタンスを前提としており、そもそも複数テナントを想定していないシステムであるという前提条件の考慮から、テナント分離の是非を評価する意味がない→Not applicable（評価対象外）の評価としているようです。
- LogProtection ー ログの保護設計自体が存在しない
設計書では、CloudTrailの扱いを明示していない点や集中ログ管理は未定義の前提があるため、そもそも保護すべきログ設計自体が存在しない→Not applicable（評価対象外）の評価としているようです。
以下のような情報不足の項目に関しては、Insufficient dataの評価を下しています。
- TrustedCryptographyBestPractices ー 暗号方式、TLS設定、鍵管理については、情報不足という評価となっています。
Not applicable や Insufficient data の判定は、「問題がない」という意味ではなく、設計書の前提条件や記載内容からは評価対象外、または判断不能であることを示しています。
人間によるアーキテクチャレビューと併用する前提とし、設計段階の一次評価としては、有効に使えるのではないかという所感です。
