セキュリティ(AWS)

本書はガバメントクラウドにおける、利用システム側の対応すべきセキュリティを理解するための文書である。本書はAWSに特化した内容であり、CSPに依らない、共通した内容は「ガバメントクラウド利用システムにおけるセキュリティ対策(共通)」として、別書となっている。「ガバメントクラウド利用システムにおけるセキュリティ対策(共通)」が親となる構成のため、「ガバメントクラウド利用システムにおけるセキュリティ対策(共通)」が未読の場合は、先にそちらを閲覧すること。

ガイドに基づくシステム構成と運用で実現するセキュリティ

本項では「ガバメントクラウド利用システムにおけるセキュリティ対策(共通)」で記述した、同名の項の内容をAWS環境で実現した場合の構成について記述する。

設計方針

責任共有モデルにおける範囲の限定

システムにEC2を使用した場合、OS、ミドルウェアなどが利用組織側の責任範囲となり、その部分のセキュリティ対策が必要となる。EC2の代わりにLambda、API Gateway、RDS、DynamoDB、ECS(Fargate)などのマネージドサービスを用いることで責任範囲を狭め、セキュリティリスクを軽減できる。

図001 EC2をマネージドサービスに置換した構成

[AWSドキュメント：責任共有モデル]
https://aws.amazon.com/jp/compliance/shared-responsibility-model/open_in_newOpens in new tab

セキュリティ対応策

多要素認証の使用

「ガバメントクラウド利用システムにおけるセキュリティ対策(共通) - 多要素認証open_in_newOpens in new tab」において言及されているように、ガバメントクラウド利用における認証では多要素認証（MFA: Multi Factor Authentication）を必須としている。

GCASからCSP環境へのシングルサインオン機能の展開後、GCAS認証の設定が各CSPの設定に優先される。したがって、以下に説明する内容はAWS環境における、ルートユーザーおよびGCAS SSO機能利用前のIAM Identity Centerのユーザー、IAMユーザーに対するMFAの設定である。

各ユーザー別のマネジメントコンソールへの認証経路は図11-aの通り。

図011-A 各ユーザーの認証経路概要

AWS環境においてMFAに使用できる認証方法は以下の三種類がある。

ガバメントクラウドでは本番相当環境へのアクセスはFIDO認定のセキュリティキーなどのハードウェアトークンが必要となる。特に本番相当環境のIAMユーザーはMFAを設定しない限りIAMロールへの切り替え（AssumeRole）ができない仕様としている。

ハードウェアTOTPトークン（TOTP: Time-based One-Time Password）はルートユーザーやIAMユーザーの認証において利用可能だが、GCASの認証ではサポートされていないためIdentity Center経由の利用には注意が必要である。また、基本的にバッテリーで動作するため、定期的な交換の考慮が必要になる。なお、AWS環境でハードウェア TOTPトークンを設定する場合は、AWSとの互換性確保のため、このリンク先（OTPトークンopen_in_newOpens in new tabまたは OTPディスプレイカードopen_in_newOpens in new tab）から購入する必要がある。

[AWSドキュメント：AWS での多要素認証 (MFA) の使用]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa.htmlopen_in_newOpens in new tab

CSP管理GUIへの接続元アクセス制御

AWS環境の管理インタフェースとしてAWSマネジメントコンソールとCLIが提供されている。AWSではマネジメントコンソールに関する接続元制御として、IAMポリシーのCondition句に接続元IPアドレスを記載し、制御対象の操作主体に適用することでアクションの許可/禁止が可能である。操作主体はIAMユーザーやIAMロール、Identity Center(IdC)のユーザーが該当する。ただし、IdCのユーザーに対してIAMポリシーによる接続制限は制約事項があるため、以下に説明する。

• Chrome Enterprise Premium（CEP）（旧 BeyondCorp Enterprise（BCE））の利用
  GCASにおけるシングルサインオン機能の利用開始後、全てのユーザーはIdCのポータル画面経由でAWSマネジメントコンソールへアクセスすることになる。その際、IdCユーザーに対する接続元IPアドレス制限はIdCコンソールの設定が可能だが管理者権限が必要なため、その操作を利用組織に開放していない。したがって、ガバメントクラウドにおいてIdCユーザーの接続元IPアドレス制限はCEPの利用が必要になる。CEPでは端末シリアル番号またはIPアドレスに基づく接続元のアクセス制御を利用可能である。詳細は「ガバメントクラウド利用システムにおけるセキュリティ対策(共通)open_in_newOpens in new tab - CSP管理GUIへの接続元アクセス元制御」を参照すること。
  CEPの利用が技術的な制約で困難な場合は、ガバメントクラウド管理組織で内容を確認するため個別に連絡すること。
• スイッチロール時の接続元IPアドレス制限
  利用システムが作成したIAMロールへのスイッチロール時の接続元IPアドレス制限は、信頼ポリシーのCondition句に”IpAddress”を用いて許可するIPアドレスを指定する形式で実現可能である。ただし、このポリシーのみでは前述の通り、Identity Centerからの対象のAWSアカウントへのログイン時には制御が適用されないことを考慮する。
  いずれの場合も、CLI利用時はアクセス制御が適用されないため注意すること。

{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Effect": "Allow",
          "Principal": {
              "AWS": "arn:aws:iam::503141165363:root"
          },
          "Action": "sts:AssumeRole",
          "Condition": {
			          "StringLike": {
			              "aws:userid": [
												"*:(Identity Centerのユーザー名)",
												"*:(Identity Centerのユーザー名)"
										]
			          },
              "IpAddress": {
                  "aws:SourceIp": [
                      "192.0.2.0/24(例)",
                      "203.0.113.0/24(例)"
                  ]
              }
          }
      }
  ]
}

スイッチロール時に接続元IPアドレスに基づく操作制限を実現する信頼ポリシーの例

リソースへのアクセス制御

リソースへのアクセス制御は主に操作権限や通信の制御を意味する。操作権限のシステム的な制御は従来、OS やアプリケーションで実装されてきたが、クラウド環境では、これに加えてAWSが提供するリソース（サービス含む）の操作に関する制御の考慮が必要になる。また、通信のアクセス制御は、AWS 特有の機能を利用したゾーニングやファイアウォールなどの利用が必要である。

本項では、特にAWS環境のリソース操作に対するアクセス制御について説明する。リソースに対するアクセス制御には、ユーザーなどリソースを操作する主体に権限を付与するアプローチ（アイデンティティベースのアクセス制御）と、アクセス制御のルールをリソースに直接適用するアプローチ（リソースベースのアクセス制御）がある。

• アイデンティティベースのアクセス制御
  IAMユーザーやIdentity Center(IdC)のユーザーなどのアクセスする主体がリソースに対してどのようにアクセスするかを制御するアプローチを意味する。AWSのほとんどのリソースはAPI で操作できるよう設計されている。この操作（アクションと呼ばれる）に対するアクセス制御のために、IAMユーザーやIdCのアクセス許可セットなどにIAMポリシーを適用する。通常のAWS環境では、IAMユーザーやIdCユーザーを作成された直後はどのような操作も許可されていない。ガバメントクラウドでは一定の役割を担うユーザーに事前に権限を付与してユーザーアカウントを払い出している。
  
  図013-a アイデンティティベースのアクセス制御イメージ

• リソースベースのアクセス制御
  AWSではリソースへの各種アクションを、リソースに直接適用するポリシーで制御可能である。これはアクセスされる対象側でどのようにアクセスされるかを制御するアプローチを意味する。この形態もアイデンティティベースのポリシーと同様に、JSON 形式のコードで記述する。例えば、S3 のバケット側に適用するポリシー（バケットポリシーと呼ばれる）であれば、S3バケットに対してアクセスを許可するユーザーを制御可能である。
  
  図013-b リソースベースのアクセス制御イメージ
  [AWSドキュメント：IAM でのポリシーとアクセス許可]
  https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.htmlopen_in_newOpens in new tab

• 最小権限の原則
  アクセス制御においては、予期せぬトラブルやインシデントを避けるため、アクセス主体への必要最小限の権限付与が重要である。これは最小権限の原則と呼ばれる。AWSではAPIによる操作が可能になり、リソースへのアクション単位でアクセス権のポリシー設計が可能である。厳密なアクセス制御が可能になりアクションの積み上げで最小権限を実現できる一方で、アクセス権の設計や運用上の負荷が著しく高まる場合がある。このため、AWS環境の利用形態に合わせて最小権限の粒度を変化させることを推奨する。
  例えば、開発環境と本番相当環境で同じようなアプローチを採用する必要はない。開発環境は保護すべきデータが存在しないように構成する。また、開発作業が遅延なくスムーズに、ときには試行錯誤しながら進められるように構成されている必要がある。このようなケースではアクション単位のIAMポリシーの設定に向いておらず、そもそもアクションを事前に想定できない。
  こうした場合は、多要素認証の設定やログの取得などのセキュリティ機構を変更されないような必要最低限の制限を実施する対応とする。
  一方で、本番相当環境については考慮する余地がある。本番相当環境として運用されている場合、その運用業務は大きく「定型的な内容」と「非定型的な内容」に分類される。

  • 定型的な内容：バックアップやサーバーの起動／停止など、システムの安定的な維持を目的とした作業内容が明確な運用業務
  • 非定型的な内容：トラブルシューティングなど、作業内容が規定できない運用業務
    「定型的な内容」については作業内容が明確であるため、アクション単位のポリシー設計が可能と考えられる。「非定型的な内容」についてはアクション単位の作業内容が不明確なため、時限的なIAMロールの払い出しと権限の付与、またはアクセスレベル単位のポリシー設計が考えられる。 アクセスレベルとは、AWSが定義するListやRead,Writeなどを指し、該当する一連のアクションが関連づけられている。IAMコンソールからIAMポリシー作成時にアクセスレベルを指定可能である。
    厳密なアクション単位の設計を行わない反面、必要に応じて発見的統制の観点から作業が正しく行われているのかを点検する。
    表013-c 最小権限の原則へのアプローチと発見的統制による補完
    
    [AWSドキュメント：ポリシー概要内のアクセスレベルの概要について]
    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_understand-policy-summary-access-level-summaries.htmlopen_in_newOpens in new tab

通信の限定と暗号化

• 通信の限定と暗号化
  Amazon CloudFrontは、高いパフォーマンス、セキュリティ、デベロッパーの利便性のために構築されたコンテンツ配信ネットワーク(CDN)サービスである。
  Webアプリケーションを使用するシステムの場合、前段としてCloudFrontを利用し、通信をHTTPSに制限することで暗号化された通信のみ許可するようにする。CloudFrontはWAFを利用でき、また、CDNであるためDDoS対策も兼ねることができる。セキュリティポリシーはTLSv1.2_2018以上を選択する。新しいものほど安全であるため、最新のTLSv1.2_2021の使用を推奨する。また、セキュリティポリシーはALBも選択可能であるため、CloudFrontと同様の基準で選択する。
  AWS Transfer FamilyはSFTP、FTPS、FTP、AS2プロトコルを利用してS3またはEFSとのファイル転送を行うサービスである。
  ファイル転送を行うシステムの場合、Transfer Familyを利用することでマネージドのSFTP、FTPSサーバーを構築できる。
  
  図002 CloudFront、Transfer Familyを使用した構成

[AWSドキュメント：Amazon CloudFront とは何ですか?]
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Introduction.htmlopen_in_newOpens in new tab

• 保管データの暗号化
  AWS Key Management Service(KMS)は、アプリケーションとAWSのサービス全体で暗号キーを作成、管理、制御できるサービスである。
  KMSで暗号化に使用するKMS Keyは以下の三種類に分類される。
  KMSキーは原則として利用システム側が主体的に管理できる暗号鍵（例：カスタマーマネージドキー）の利用を強く推奨する。詳細は「ガバメントクラウド利用システムにおけるセキュリティ対策(共通)」-「保管データの暗号化」open_in_newOpens in new tabを確認すること。

なお、S3バケットはデフォルトで暗号化されるほか、RDSではAWSマネジメントコンソールからの利用時に暗号化される選択になっているが、AWS 所有のキーで暗号化されるため、暗号鍵の選択に留意すること。EC2で利用するEBSの暗号化についても留意すること。

[AWSドキュメント：AWS Key Management Service]
https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/overview.htmlopen_in_newOpens in new tab

• シークレットの管理
  AWS Secrets Managerは、データベース認証情報、API キー、その他のシークレットのライフサイクルを通しての管理、取得、ローテーションできるようにするサービスである。Secrets ManagerはKMSと統合されており、シークレットは暗号化されて保存される。シークレットはコード内や環境変数に保存せず、Secrets Managerで管理することにより、セキュリティリスクを軽減することができる。

図003 RDSのシークレットをSecrets Managerに保存する場合の動作

[AWSドキュメント：AWS Secrets Manager の概要]
https://docs.aws.amazon.com/ja_jp/secretsmanager/latest/userguide/intro.htmlopen_in_newOpens in new tab

WAF/ファイアウォール

WAFとは

AWS WAFはアプリケーション層でトラフィックを監視し、事前に設定したルールに従いウェブリクエストを許可、拒否、またはカウントすることができる。AWS WAFはAmazon CloudFront、Application Load Balancer(ALB)、Amazon API Gateway、そしてAWS AppSyncへデプロイすることが可能である。

図004 WAFを使用した構成

• WAFのルールについて
  AWS WAFに適用できるルールは以下の三種類に分類される。

[AWSドキュメント：AWS WAF]
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/waf-chapter.htmlopen_in_newOpens in new tab

• AWS WAF導入の検討
  AWS WAFを導入する場合、AWSマネージドルールの適用に加え、カスタムルールの継続的な更新が推奨される。 WAFのルールの最適化を自動で行うサービスの導入も効果的な選択肢である。
  またWAFのルールはカウントルールとしてWAFに適用すると、通信には影響を与えずにルールに当てはまるトラフィック数を計測することができ、許可ルールや拒否ルールとして適用した場合の影響を分析することができる。新しいルールを適用する際は、予期せず正常なトラフィックを拒否してしまうなどの事故を予防するため、まずはカウントルールとして適用が推奨される。

AWS上でのファイアウォール

AWSでは以下のサービスがファイアウォールとして機能する。

図005 Security GroupとAdvancedの動作

図006 AWS Network Firewall アウトバウンドの動作

図007 AWS Network Firewall インバウンドの動作

[AWSドキュメント：セキュリティグループを使用してリソースへのトラフィックを制御する]
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_SecurityGroups.html\open_in_newOpens in new tab
[AWSドキュメント：ネットワーク ACL を使用してサブネットへのトラフィックを制御する]
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-network-acls.html\open_in_newOpens in new tab
[AWSドキュメント：What is AWS Network Firewall?]
https://docs.aws.amazon.com/ja_jp/network-firewall/latest/developerguide/what-is-aws-network-firewall.htmlopen_in_newOpens in new tab

• ファイヤーウォール導入の検討
  Security GroupとNACLを利用し通信に必要なIPレンジとポートのみ開放されているべきである。また、Security GroupとNACLのどちらか一方のみで前述の状態が構築できる場合においても、Security GroupとNACL両方のサービスを利用した二段防御の構築が推奨される。送信先外部ドメインを制限したいなどSecurity GroupとNACLでは満たせない要件がある場合、AWS Network Firewallは効果的な選択肢となり得る。

DDoS対策

AWS上のDDoS対策サービスであるAWS Shieldは、StandardとAdvancedの二種類存在する。

図008 AWS Shield StandardとAdvancedの比較

[AWSドキュメント：AWS Shield]
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/shield-chapter.htmlopen_in_newOpens in new tab

• AWS Shield Advanced導入の検討
  AWS Shield Advancedはガバメントクラウドでは有効化されている。ただし、機能させるためには保護リソースを設定する必要があるため、インターネットに接続し、保護対象のリソースを使用しているシステムの場合は設定を行うことを推奨する。また、SRTサポートも有効化し、サポートを受けられる状態にすることを推奨する。
  インターネットに接続していないシステムの場合、Shield Advancedは不要であるため、むやみに機能の有効化は行わないこと。

マルウェア対策

マルウェア対策として最も効果的なのは、EC2を使用せず、マネージドサービスを利用してOSを責任範囲外とすることである。具体的には責任共有モデルにおける範囲の限定を参照。

EC2を使用する場合、マルウェア対策に使用できるAWSサービスとして、ウイルスを含むマルウェアの攻撃の検出にAmazon GuardDutyが利用できる。GuardDutyは機械学習を行い、AWS環境への攻撃を検知するサービスである。GuardDutyは検出を行うのみで、駆除は行わないため、検出された場合は対象のファイルを削除するなどの対処を行うこと。

図009 GuardDutyの動作

[AWSドキュメント：Amazon GuardDuty とは]
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/what-is-guardduty.htmlopen_in_newOpens in new tab

• Amazon GuardDuty導入の検討
  GuardDutyは環境払い出し時に有効になっているため、導入を検討する必要はない。

脆弱性対策

脆弱対策として最も効果的なのは、EC2を使用せず、マネージドサービスを利用してOS/ミドルウェアを責任範囲外とすることである。具体的には責任共有モデルにおける範囲の限定を参照。

EC2を使用する場合、脆弱性対策に使用できるAWSサービスとして、Amazon InspectorとAWS System Managerの機能の一つであるパッチマネージャーが利用できる。

図010 EC2インスタンスに対するInspectorの動作
※コンテナイメージに対する動作はCI/CDを参照。

図011 パッチマネージャーの動作

[AWSドキュメント：Amazon Inspector とは]
https://docs.aws.amazon.com/ja_jp/inspector/latest/user/what-is-inspector.html\open_in_newOpens in new tab
[AWSドキュメント：AWS Systems Manager Patch Manager]
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-patch.htmlopen_in_newOpens in new tab

• Amazon Inspector導入の検討
  EC2を使用している場合は脆弱性対策は必須であるため、Inspectorの使用を推奨する。また、Inspectorは一旦有効化すれば指定したタイミングで自動的にスキャンを行うため、セキュリティ対策の負担を軽減できる。
• パッチマネージャー導入の検討
  パッチマネージャーを使用してパッチの管理を行う場合、開発環境でテストを行ったパッチベースラインと同内容のパッチベースラインを本番環境に適用することにより、手動で適用する場合と比較してオペレーションミスの軽減や作業時間の短縮などのメリットがある。また、メンテナンスウィンドウを設定すれば、システムが稼働していない時間帯にパッチの自動適用が可能となる。EC2を使用している場合は脆弱性対策は必須であり、運用の負荷軽減のためにパッチマネージャーの使用を推奨する。

CI/CD

AWS CodePipelineはアプリケーションをリリースするために必要なステップのモデル化、視覚化、および自動化に使用できる継続的な配信サービスである。内部ではCodeCommit、CodeDeployなどの他のサービスと連携しており、連携に必要な権限はCodePipelineに付与するIAMロールによって制御する。
また、パイプラインに組み込み、脆弱性の発見に使用できるサービスとして、CodePipelineのアクションに対応している脆弱性スキャン用のサービスであるAmazon InspectorとAmazon CodeGuruが使用できる。

Amazon Inspectorに関しては脆弱性対策を参照。

Amazon CodeGuruは機械学習により、コードの脆弱性やペストプラクティスにマッチしない記述、最もコストのかかるコード行を発見し、推奨事項を提示する。CodeCommit、Gitなどのリポジトリサービスと連携することができ、プルリクエストごとに自動的にスキャンを行う。

図014 セキュリティを考慮したCI/CD環境

[AWSドキュメント：AWS CodePipeline の概要]
https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/welcome.html\open_in_newOpens in new tab
[AWSドキュメント：Amazon インスペクターで Amazon ECR コンテナイメージをスキャンする]
https://docs.aws.amazon.com/ja_jp/inspector/latest/user/enable-disable-scanning-ecr.html\open_in_newOpens in new tab
[AWSドキュメント：What is Amazon CodeGuru Reviewer?]
https://docs.aws.amazon.com/ja_jp/codeguru/latest/reviewer-ug/welcome.htmlopen_in_newOpens in new tab

• CI/CDのセキュリティの検討
  CI/CD環境のセキュリティはCodePipelineにアクセスするIAMユーザーまたはIAMロール、CodePipelineに付与するIAMロールの権限を最小限にし、セキュア化することで確保する。また、コードのマージは、開発者の独断で行わず、プルリクエストを作成し、レビュアーの承認を得てから実施する。
  コンテナ、コンテナ内のOS、ミドルウェア、プログラム言語パッケージのセキュリティはECRのイメージスキャンを利用する。基本スキャンは無料だが、プログラム言語パッケージのスキャンは出来ないため、拡張スキャンを推奨。
  コードの脆弱性のチェックは、Amazon CodeGuruを利用する。手動でスキャンを行うこともできるが、プルリクエスト時に自動的にスキャンが実行されるようにすることで、チェック漏れを防ぐことが出来るため、パイプラインに組み込んで使用することを推奨する。

ログの取得と分析

ログの取得

ログの取得方法は環境によって異なる。

• AWSアカウントのアクティビティログ
  AWS CloudTrailは、AWSインフラストラクチャ全体のアカウントアクティビティをモニタリングして記録し、ストレージ、分析、および修復アクションをコントロールするサービスである。AWSリソースに対するAPIコール、マネジメントコンソールの操作、AWSリソースの変更などを記録し、セキュリティとコンプライアンスを向上させることができる。

  • AWS CloudTrail導入の検討
    AWS CloudTrailは環境払い出し時に有効化されているため、導入を検討する必要はない。ログは９０日間保存され、以降のログは削除されるため、必要に応じてS3に保存するなどの追加設定を行う。

• AWSサービスが生成するログ
  Amazon CloudWatch LogsはAWSサービスやアプリケーションから生成されたログを集中管理するサービスである。VPC、S3、RDS、ECS、EC2(ClouWatchエージェントが必要)などのログを監視、分析、アーカイブすることができる。

  • Amazon CloudWatch Logs導入の検討
    Amazon CloudWatch Logsが使用できるサービスでは、他の手段でログを取得している場合を除き、使用することを推奨する。
    特に、アプリケーションログはデバッグ、パフォーマンス監視、インシデント発生時の原因調査等のため、必ずログを保存すること。
    ECSを使用する場合はログドライバの指定でawslogsを選択することでCloudWatch logsに転送が可能だが、複雑な設定は出来ない。転送先の振り分け、ログの加工、Amazon Kinesis Data Firehoseへの転送などの要件がある場合は、awsfirelensを使用する。
    ログの保存先にCloudWatch LogsではなくS3を選択できる場合があるが、コストが抑えられる反面、検索やフィルタなどの機能は使用できなくなるため、検索性が低下する。どちらが適切な保存先であるかを検討の上、選択すること。
    ログの保存期間は要件によるが、コストとのバランスを考え、不要に長期間保存しないこと。

ログの分析

Amazon Detective を使用すると、セキュリティに関する検出結果や疑わしいアクティビティの根本原因の分析、調査、および迅速な特定を行うことができるサービスである。機械学習、統計分析、グラフ理論を使用して、セキュリティ調査をより迅速かつ効率的に行うのに役立つビジュアライゼーションを生成する。Amazon Detective は以下のタイプの AWSサービスからデータを自動的に取得する。
・AWS CloudTrail ログ
・Amazon VPC フローログ
・Amazon GuardDutyの調査結果
・AWS Security Hubの調査結果
・Amazon EKS監査ログ

図015 Detectiveの動作

[AWSドキュメント：Amazon Detective とは]
https://docs.aws.amazon.com/ja_jp/detective/latest/adminguide/what-is-detective.htmlopen_in_newOpens in new tab

• Amazon Detective導入の検討
  Amazon Detectiveを利用した場合、Security Hub、GuardDutyの調査結果をグラフ化することでより包括的な分析が可能になり、それぞれのサービスを単独で利用する場合より、潜在的なセキュリティ問題が特定しやすくなる。セキュリティ調査と効率性と精度の向上が期待できるため、利用を推奨する。

構成変更の記録と自動検知

AWS ConfigはAWSリソース構成の変更を継続的に評価、モニタリング、記憶して変更管理を簡素化するサービスである。構成に変更があった場合、管理者に通知を行う。また、変更内容をあらかじめ設定したConfig Ruleによって評価し、結果をダッシュボードに表示できる。過去の変更履歴をスナップショットとして保存することができ、変更前後の構成内容を比較可能。

図016 Configの動作

[AWSドキュメント：AWS Config とは?]
https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/WhatIsConfig.htmlopen_in_newOpens in new tab

• AWS Config導入の検討
  AWS Configは発見的統制の構成要素であり、環境払い出し時に有効化されているため、導入を検討する必要はない。Config Ruleの追加は可能なので、必要に応じてルールの追加を行う。

ベンチマーク/ベストプラクティス自動チェック

CIS Benchmarks

Center of Internet Security(CIS) Benchmarksは、世界的に認められたコンセンサス主導の一連のベストプラクティスが記載されたガイドラインである。対象はOS、ミドルウェア、ネットワークなどと幅広く、140種類以上のベンチマークが発行されている。AWSを対象としたベンチマークも存在し、これを利用することでCISのベストプラクティスに沿ったシステムを構築できる。

• CIS Benchmarks導入の検討
  CIS BenchmarksはSecurity Hubのセキュリティ基準として用意されており、デフォルトで有効化されている。Security Hubは発見的統制の構成要素であり、環境払い出し時に有効化されているため、導入を検討する必要はない。検出結果はSecurity Hubのダッシュボードで確認できる。

[AWSドキュメント：CIS AWS Foundations Benchmark]
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-standards-cis.htmlopen_in_newOpens in new tab

AWS 基礎セキュリティのベストプラクティス

AWS 基礎セキュリティのベストプラクティスは、AWSが提供するセキュリティのベストプラクティスを元に定義された、一連の統制である。これを利用することでAWSのベストプラクティスに沿ったシステムを構築できる。

• AWS 基礎セキュリティのベストプラクティス導入の検討
  AWS 基礎セキュリティのベストプラクティスはSecurity Hubのセキュリティ基準として用意されており、デフォルトで有効化されている。Security Hubは発見的統制の構成要素であり、環境払い出し時に有効化されているため、導入を検討する必要はない。検出結果はSecurity Hubのダッシュボードで確認できる。

[AWSドキュメント：AWS Foundational Security Best Practices 標準]
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-standards-fsbp.htmlopen_in_newOpens in new tab

AIによる不正自動検出

AWSのAIによる不正自動検出サービスには、Amazon GuardDutyとAmazon Fraud Detectorがある。GuardDutyについてはウイルス対策を参照。
Fraud Detectorは機械学習を使用してデータを分析し、オンライン支払詐欺や偽アカウントの作成などの不正行為を検出するサービスである。サンプルデータを元に作成した機械学習モデルにより、自動的かつ迅速に不正を検出する。

図017Fraud Detectorの動作

[AWSドキュメント：Amazon Fraud Detector とは]
https://docs.aws.amazon.com/ja_jp/frauddetector/latest/ug/what-is-frauddetector.htmlopen_in_newOpens in new tab

• Amazon Fraud Detector導入の検討
  Amazon Fraud Detectorは数ステップで設定が完了するため、機械学習の経験がなくても利用は可能である。不正行為の手法は日々増加し、多様化しており、機械学習を用いない場合は検出が困難である。これらの理由により、オンラインシステムを運用する場合は導入を検討する。
  2024年5月時点では東京、大阪リージョンでは利用できないことに注意。

運用

定期的な改善活動

セキュリティ水準を保つためには、日々の運用の中で問題点の検出と対応を行い、改善していくことが重要となる。具体的な内容については技術マニュアル「発見的統制内容説明(AWS)」の「発見時のアクション」を参照。

不正使用報告への対応

アカウントの保有リソースがスパムの送信、ポートスキャン、DDoS攻撃、著作権を侵害するコンテンツのホスティング、マルウェアの配布など不正な行為に使用されている疑いがある場合、AWS Trust & Safetyチームからルートユーザーのメールアドレス及び代替連絡先となる「セキュリティに関する連絡先」に関連するログなどが含まれた不正使用報告（英文メール）が送信される。なお、ルートユーザーのメールアドレスはデジタル庁にて管理するため、利用システム側で代替連絡先となる「セキュリティに関する連絡先」へメールアドレスを必ず登録しておくこと。

※不正使用報告（Abuse Report）メール
送信元：trustandsafety@support.aws.comなど
メールタイトル（例）：Your AWS Abuse Report [Abuse report number] [AWS account ID]

不正使用報告を受信した場合、以下の対応を行う。

1. メール受信後24時間以内に、不正使用通知の報告メールに直接返信（初回応答）する。初回応答の時点で対処まで完了している必要はなく、報告を認識し調査を開始したことを伝えるためAWS Trust & Safetyチームのメールに返信する。（その際、受信したメールの件名は変更しない）また、調査にあたって詳細情報が必要な場合はAWS Trust & Safetyチームからのメール返信によりリクエストを行う。
   ※24時間以内に不正通知に応答しない場合、リソースのブロック、AWSアカウント一時停止の措置が行われる場合がある
2. 調査の結果、不正行為に該当すると判断した場合、再発を防ぐために講じた措置について返信する。または、指摘された不正行為が該当しないと判断した場合はその旨回答する。
   ※ログの確認方法等が不明な場合など技術的なサポートが必要な場合、AWSサポートにサポートケースを起票する
3. AWS Trust & Safetyチームは回答内容を確認し今後の対応が決定される。

テンプレートを使って構築することで実現されるセキュリティ

本項では「ガバメントクラウド利用システムにおけるセキュリティ対策(共通)」で記述した、同名の項の内容に加え、AWS環境でテンプレートを使用した際にセキュリティ向上につながる内容について記述する。
尚、AWSにはテンプレートとしてCloudFormationが利用できるが、ガバメントクラウドではCDKを使用しているため、CDKについて記述する。

CDKとConstructの利用

ConstructはCDKの基本的な構成要素で、AWSの各リソースをカプセル化したものである。ConstructはL1からL3までのレベルに分かれており、高レベルになるほど抽象化の水準が上がる。高レベルのConstructほど記述量が減り、AWSが用意するベストプラクティスを内包するため、セキュリティの欠陥の減少が期待できる。
Constructのレベルごとの詳細を以下に示す。

[AWSドキュメント：コンストラクト]
https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/constructs.htmlopen_in_newOpens in new tab

• Constructの利用の検討
  L1はCloudFormationと同量の記述が必要になるためCDKのメリットが薄まり、L3は記述量は最も少ないが、その分用途が特化されているため、システムにマッチしない可能性が高い。従って、抽象化と扱いやすさのバランスの良いL2の利用を推奨する。

CDK用のセキュリティツールの利用

CDKにはcdk-nagというセキュリティツールが用意されている。cdk-nagを使用した場合、Constructがベストプラクティスに準拠した内容であるかをチェックすることができる。

[AWSドキュメント：AWS Cloud Development Kit と cdk-nag でアプリケーションのセキュリティとコンプライアンスを管理する]
https://aws.amazon.com/jp/blogs/news/manage-application-security-and-compliance-with-the-aws-cloud-development-kit-and-cdk-nag/open_in_newOpens in new tab

• cdk-nagの利用の検討
  非準拠の内容は修正するか、理由を記述しなけばデプロイできないため、未発見のセキュリティの欠陥を内包したままアプリケーションをデプロイするリスクを軽減できるようになる。コード内容のチェックの工数削減効果もあるため、利用を推奨する。

改訂履歴