データベースのパスワードやAPIキーといった機密情報を、コードやコンテナイメージにハードコードするのは重大なセキュリティリスクです。本記事ではAWSが提供する 2つの機密情報管理サービスを比較します。

SAA レベル：基礎概念

2つのサービスの基本比較

項目	Secrets Manager	Systems Manager Parameter Store
主な用途	データベース認証情報等の機密情報	設定値全般（機密・非機密問わず）
自動ローテーション	ネイティブサポート（RDS等と統合）	標準機能にはない（Lambda等で自前実装が必要）
コスト	保存する秘密情報ごとに課金	標準パラメータは無料、詳細パラメータのみ課金

SAA 試験のポイント

「コストを抑えたいだけの単純な設定値の保存」であればParameter Store、「自動ローテーションが必要なデータベース認証情報」であればSecrets Manager、という基本的な使い分けがSAAで問われます。

Parameter Storeの階層構造

/app/prod/db/passwordのように、階層的な名前空間でパラメータを整理できる
IAMポリシーでパス単位のアクセス制御が可能

SAP レベル：高度な設計シナリオ

Secrets Managerの自動ローテーション

SAP 試験のポイント

Secrets Managerは、RDS/Aurora/Redshift等と統合されたLambdaベースの自動ローテーションをサポートします。ローテーション用Lambda関数が、新しいパスワードを生成し、データベース側のパスワードを変更し、Secrets Manager内のシークレットを更新する、という一連の流れを自動化できます。これにより、人手を介さず定期的にクレデンシャルを更新し、漏洩時の被害ウィンドウを最小化する設計が可能になります。

コストと機能のトレードオフによる使い分け

SAP 試験のポイント

大量の設定値（数千件規模）を扱う場合、Secrets Managerでは秘密情報ごとの課金がコストに直結するため、機密性が低い設定値（非機密の環境変数等）はParameter Store、真に機密性が高くローテーションが必要な認証情報のみSecrets Managerという使い分けが、コスト最適化の観点でSAPレベルの判断として問われます。Parameter StoreもKMSで暗号化された「SecureString」タイプのパラメータとして機密情報を扱うことは可能ですが、自動ローテーションが必要な場合はSecrets Managerを選ぶ必要があります。

クロスアカウントでの参照

Secrets Managerのリソースベースポリシーを使い、他のAWSアカウントから特定のシークレットへの読み取りアクセスを許可できる
共有サービスアカウントに集約されたデータベース認証情報を、複数のワークロードアカウントから安全に参照する設計パターンで使われる

設計上の落とし穴

「Parameter StoreのSecureStringも暗号化されているから、Secrets Managerと同じセキュリティレベル」と考えるのは不十分です。ローテーション機能の有無という運用上の重要な差があり、ローテーションされないクレデンシャルは、漏洩時のリスクウィンドウが長期化するというセキュリティ上のトレードオフをSAPでは考慮する必要があります。

ECS/EKSタスクへの機密情報の受け渡し

ECSタスク定義やEKSのSecrets Store CSI Driverと連携し、コンテナ起動時に環境変数やファイルとしてSecrets Manager/Parameter Storeの値を安全に注入する設計が一般的
コンテナイメージやアプリケーションコードに機密情報を一切含めない、という原則を徹底する

まとめ

SAA: Secrets ManagerとParameter Storeの基本的な役割分担、コストと機能の違いを理解する。
SAP: 自動ローテーションの仕組み、大量の設定値を扱う際のコスト最適化の使い分け、クロスアカウント参照の設計ができる。

次は **VPCセキュリティ設計（NACL、SG、プライベートサブネット構成）**を見ていきましょう。