Amazon SOA-C02: セキュリティ、アイデンティティ、およびコンプライアンス — 学習ガイド

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS SysOps Administrator Associate SOA-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

このドメインでは、安全でコンプライアンスに準拠したAWS運用の基盤となる、ID、暗号化、シークレット、監査の基本要素について説明します。適切なアクセス権を付与し（最小権限の原則）、キー管理と暗号化によってデータを保護し、継続的なコンプライアンスのために不変の監査証跡を作成することに焦点を当てています。日々のSysOpsの責任範囲には、IAMロールと信頼境界の設計、KMSキーとシークレットの運用、AWS ConfigとCloudTrailを使用したドリフト（設定変更）やポリシー違反の検出などが含まれます。

IAM、ロール、ポリシー、フェデレーション

IAMガバナンスは、ロールの分離と最小権限から始めるべきです。管理、ロギング、アプリケーションワークロードにはそれぞれ別のロールを使用し、AdministratorAccessのような広範なポリシーを存続期間の長いプリンシパルにアタッチすることは避けてください。信頼ポリシー（コンソールまたはCLI: aws iam create-role --role-name AppRole --assume-role-policy-document file://trust.json）を使用してロールを作成し、aws iam put-role-policyまたはマネージドポリシーを使用して許可ポリシーをアタッチします。許可の境界とIAM Conditions（aws:SourceIp、aws:RequestedRegion）を使用して、権限がどこで、どのように行使できるかを制限します。

IDフェデレーションでは、STSを介して一時的な認証情報を発行するために、SAML/OIDCを優先します。SAMLの場合、IAMでIDプロバイダーを設定し、aws sts assume-role-with-saml --role-arn arn:aws:iam::123456789012:role/SAMLRole --principal-arn arn:aws:iam::123456789012:saml-provider/IdPを使用します。OIDC（Cognito、Auth0、またはその他のプロバイダー）の場合、IAM OIDCプロバイダーを作成し、クレームをロールにマッピングします。ウェブIDフェデレーションではaws sts assume-role-with-web-identityを使用します。ユーザーが外部にいる場合や、中央のディレクトリサービスが認証を管理する場合は、フェデレーションロールを選択します。一元的なエンタープライズアクセスとセッション管理には、AWS IAM Identity Center (SSO) を使用します。

KMS、キー管理、暗号化

KMSは、キーのライフサイクルとアクセス制御のための中核となるサービスです。AWSマネージドキー（シンプルさ）、AWS所有のキー、カスタマーマネージドCMK（きめ細かな制御）の中から選択します。aws kms create-key --description "CMK for prod"でCMKを作成し、aws kms enable-key-rotation --key-id alias/ProdKeyで自動ローテーションを有効にします。キーポリシーを使用してキーを管理できるユーザーを定義し、広範なIAMポリシーではなく、一時的なアクセス委任にはグラント（aws kms create-grant）を使用します。

判断基準: 監査とキーのライフサイクル管理（ローテーション、削除期間）が必要な場合はCMKを使用します。多くのマネージドサービスで自動化による利便性を求める場合は、AWSマネージドキーを使用します。IAMポリシーとキーポリシーを組み合わせて適用し、キーを保護します。クロスアカウントでの使用には、kms:ViaServiceやKMSグラントを介して使用を制限し、即時削除をスケジュールすることは避け、最小限の待機期間を使用します。CloudTrailログでEncrypt/DecryptおよびGenerateDataKeyオペレーションのKMS使用状況を監視し、異常な使用を検出します。

シークレット管理とパラメーターストア

認証情報のローテーションとライフサイクル自動化にはAWS Secrets Managerを、ローテーションが手動である、よりシンプルなシークレットにはSystems Manager Parameter Store (SecureString) を使用します。aws secretsmanager create-secret --name prod/db --secret-string '{"username":"app","password":"..."}'でシークレットを作成し、自動ローテーションのためにLambda関数を指定してローテーションを有効化します。Parameter Storeの場合は、aws ssm put-parameter --name /prod/db/password --value "..." --type SecureString --key-id alias/ProdKeyを使用します。

判断のポイント:

Secrets Manager: 組み込みのローテーション、シークレットのバージョン管理、レプリケーション、統合されたコンソールローテーションテンプレートを備えています。コストは高くなりますが、DB認証情報やAPIキーに適しています。
Parameter Store SecureString: 基本的なシークレット保管のための無料利用枠があり、暗号化にはKMS CMKを、アクセスにはIAMポリシーを使用します。常に最小権限のIAMポリシーを介してシークレットへのアクセスを制限し、コードや環境変数に存続期間の長い認証情報を埋め込むのではなく、ロールベースのアクセス（EC2/ECS/Lambda実行ロール）を優先します。

AWS Config、監査、コンプライアンス監視

AWS Configは、継続的なリソース記録、変更履歴、ルール評価を提供します。レコーダーと配信チャネルを有効にし（コンソールまたはaws configservice start-configuration-recorder）、aws configservice put-config-ruleでマネージドルールまたはカスタムルールを作成します。ConfigをCloudTrail（aws cloudtrail create-trail --name audit --s3-bucket audit-bucket）およびCloudWatch Alarmsと組み合わせることで、ほぼリアルタイムの検出と修復が可能になります（Config修復アクションまたはSystems Manager Automationドキュメントを使用）。

設計上の決定事項: 標準的なチェック（S3バケットのパブリック読み取り、ルートアカウントのMFA）にはConfigマネージドルールを使用し、ドメイン固有の制御にはカスタムルール（Lambda）を使用します。Configデータをアグリゲーターに集約するマルチリージョン集約を確保し、AWS Organizationsを介してマルチアカウント記録を有効にします。CloudTrailログを一元管理された暗号化S3バケット（SSE-KMS）に送信して不変の監査証跡を維持し、異常なAPIアクティビティに対してCloudTrail Insightsを有効にします。

データ保護、転送中および保管時の暗号化

暗号化は階層的に適用されるべきです。保管時はEBS、RDS、S3（SSE-S3、SSE-KMS、またはSSE-C）にKMSベースの暗号化を使用し、転送時はアプリケーションのトラフィックにTLSを使用します（パブリック/プライベート証明書にはACMを使用し、ALB/NLBリスナーにアタッチします: aws elbv2 create-listener --load-balancer-arn ... --protocol HTTPS --port 443 --certificates CertificateArn=arn:aws:acm:...）。追加の制御が必要な場合はクライアントサイド暗号化を使用し、KMSのクォータを超える大規模なデータを暗号化する場合は、GenerateDataKeyを使用したエンベロープ暗号化を検討します。

以下の判断基準を適用します:

監査とキーへのアクセス制御が必要なS3オブジェクトにはSSE-KMSを使用します。基本的なサーバーサイド暗号化にはSSE-S3で十分です。
キーのローテーションとクロスアカウントのアクセス制御が必要なEBSおよびRDSにはKMS CMKを使用します。
サービスエンドポイントには常にTLSを強制します。ロードバランサーではHSTSと強力な暗号スイートを使用します。VPCエンドポイントとIAMポリシーを使用して、データプレーンAPIのパブリックな露出を減らします。

一般的な落とし穴と判断基準

ルートアカウントの過剰な使用やルート認証情報の保管: 代わりに、MFAを設定した管理者ロールを作成し、日常業務にはAWS SSOやIAMロールを使用します。ルート認証情報は安全な保管庫に保管し、MFAを有効化します。
長期的なアクセスキーへの依存: キーを定期的にローテーションするか、STSとロールチェーン（EC2/ECS/Lambdaロール）を介した一時的な認証情報を使用することでキーを廃止します。
KMSキーやシークレットのローテーション漏れや不適切な保護: 適切な場合はCMKの自動ローテーションを有効にし、DB認証情報にはSecrets Managerのローテーションを使用し、CloudTrailを介してキーの使用状況を監視します。
S3のデフォルトのアクセス許可やACLへの依存: バケットポリシーを強制し、パブリックアクセスをブロックし、機密データにはSSE-KMSを使用します。AWS Configルールで検証します。
キーポリシーとIAMポリシーの誤用: KMSキーポリシーでキーの管理を行い、適切な場合はグラントやIAMを通じて使用を許可します。Decrypt権限を広範囲に付与しないようにします。
ログの一元化とマルチリージョン集約の失念: クロスアカウントのコンプライアンスのために、CloudTrailのマルチリージョントレイルとConfigアグリゲーターを設定します。

実践的な問題: ユースケースシナリオ

フィンテック企業であるAcmeFin社は、本番データベースとAPIを保護しつつ、請負業者に一時的なアクセスを提供し、コンプライアンス監査のための監査可能性を維持する必要があります。

管理者、アプリケーション、請負業者アクセス用に個別のIAMロールを作成します。MFAを強制し、請負業者向けにはSAMLベースのフェデレーションのためにIAM Identity Centerを使用します。
カスタマーマネージドCMK（aws kms create-key）でRDSとEBSを暗号化し、キーのローテーションを有効にし、DBロールと監査ロールのみを許可する厳格なキーポリシーを介してキーの使用を制限します。
提供されているLambdaローテーションテンプレートを使用して、自動ローテーションを設定したAWS Secrets ManagerにDB認証情報を保存します。
CloudTrail（マルチリージョン）とAWS Configレコーダーを有効にし、ログをSSE-KMSで暗号化された中央のS3バケットに送信し、パブリックS3や暗号化されていないリソースに対するConfigルールを作成します。
HTTPSのためにACM発行の証明書を持つALBを使用し、適切な場合はAPIをWAFとVPCエンドポイントの背後に配置します。

このアプローチは、ロールの分離によって最小権限を強制し、認証情報とキーのローテーションを自動化して影響範囲を縮小し、ログとConfigの評価を一元化することで、運用チームが安全な一時的アクセスパターンを維持しながら、監査人が統制を検証できるようにします。

← デプロイ、プロビジョニング、および自動化 · すべてのドメイン · ネットワーキングとコンテンツ配信 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →