シークレットと認証情報の管理 Secrets ManagerとParameter Storeで平文をなくす

「データベースのパスワードがソースコードに直書きされている」「APIキーが環境変数に平文で入っている」。SCS-C02ではこうした状況を安全な構成へ置き換える問題が繰り返し出ます。ポイントは要件に「自動ローテーション」「コスト最小」「クロスアカウント共有」のどれが書かれているかでサービスを選び分けることです。

覚え方は「保管する・自動で入れ替える・渡す」の3つの観点

シークレット管理は、値を暗号化して保管する層、期限が来たら自動で新しい値に入れ替える層、そしてアプリケーションへ安全に渡す層の3つに分けて考えます。保管はSecrets ManagerまたはSystems Manager Parameter Store、入れ替えはSecrets Managerのローテーション、渡すのはIAMロールという役割分担が基本形です。

AWS Secrets Manager

KMSで暗号化した文字列を保管し、Lambdaのローテーション関数によってデータベースのパスワードを定期的に自動更新できるのが最大の特徴です。RDS、Aurora、Redshift、DocumentDBについてはマネージドなローテーション関数が提供されており、30日ごとの入れ替えといった要件をコードなしで満たせます。使いどころは「90日ごとにDB認証情報をローテーションすること」という監査要件がある場合や、リソースベースポリシーで別アカウントのアプリケーションに読ませたい場合です。

Systems Manager Parameter Store

設定値とシークレットの両方を階層構造（prod-app-db-host のようなパス）で保管します。SecureString型を選ぶとKMSで暗号化され、標準パラメータは追加費用なしで利用できます。使いどころは、ローテーションが不要な外部SaaSのトークンや、環境ごとの接続先設定など「数が多く、コストを抑えたい」ケースです。

IAMロールで「そもそも渡さない」

AWSサービスへのアクセスであれば、そもそも長期のアクセスキーを保管しないのが最善です。EC2のインスタンスプロファイル、ECSのタスクロール、EKSのサービスアカウント用IAMロール（IRSA）、LambdaのIAMロールを使えば、一時的な認証情報が自動で供給・更新されます。使いどころは、選択肢に「IAMロールを使う」と「アクセスキーを安全に保管する」が並んでいる場合で、原則として前者が正解です。

チェックリスト

• Secrets Managerのローテーションが4段階（createSecret、setSecret、testSecret、finishSecret）で進むことを説明できる
• AWSStagesのAWSCURRENTとAWSPENDINGの役割を区別できる
• Parameter Storeの標準パラメータと高度なパラメータの違い（サイズ上限とポリシー）を言える
• EC2やECSからのアクセスにアクセスキーではなくロールを使う理由を説明できる
• シークレットへのアクセスをKMSキーポリシーとIAMポリシーの両方で制御できることを理解している

まとめ

シークレット管理は「保管・ローテーション・受け渡し」の3層で考えると、選択肢の絞り込みが一気に楽になります。まずIAMロールで済まないかを疑い、次にローテーション要件の有無でSecrets ManagerとParameter Storeを選び分けてください。 理解度の確認にはクイズが便利です。試験範囲や申し込みの最新情報はAWS認定 公式ページもあわせて確認してください。