コードからのシークレットの削除と安全な管理
ベストプラクティス: コードにシークレットをハードコーディングしない
コードにシークレットを保存することは、認証情報が意図せずに公開や露出する可能性がある間違いです。
ハードコーディングされたシークレットがアクセスキーの場合は、「一時的な認証情報の使用 」の推奨事項を確認してください。
コードから長期的な認証情報を使用するサービスにアクセスする必要がある場合は、AWS Secrets Manager を活用して、認証情報はローテーションして、必要な時に取得してください。
アプリケーションからシークレットやパスワードにアクセスする場合も、「一時的な認証情報の使用 」の推奨事項で説明されているのと同様の方法で機能します。インスタンスはインスタンスプロファイルから、AWS Secrets Manager からシークレットを取得する権限を得ます。アプリケーションはパスワードを取得して、リソースに接続するために使用します。
オープンソースの git-secrets を使用すると、コードを確認しコード内のシークレットを特定できます。
AWS Secrets Manager のベストプラクティス
https://docs.aws.amazon.com/ja_jp/secretsmanager/latest/userguide/best-practices.html
Well-Architected Framework の推奨事項マッピング
- SEC02-BP05 定期的に認証情報を監査およびローテーションする
主なリスクと軽減
- シークレット(パスワード/プライベートキー/アクセスキーといった認証情報)がコードに保存されていると、テスターやレビュアーなどコードをレビューする権限を持つ人が、それらの認証情報を取得してコード外で使用したり、攻撃者に売却したりする可能性があります。
- 開発者が GitHub などの公開リポジトリでオープンソースコミュニティと共有し、認証情報が公開される可能性があります。
- 攻撃者は公開リポジトリでアクセスキーなどの認証情報を探します。
- ハードコードされたシークレットはローテーションが難しいです (特に既知の侵害があり、即座にローテーションする必要がある場合に重要です)。
- これらのリスクは、コードと同じリポジトリに保存された設定ファイルにも適用されます。
評価のガイダンス
- データベースのパスワードなどのシークレットを保存およびローテーションするために AWS Secrets Manager や同様のソリューションを活用していますか?
- コードにシークレットが保存されていないことを管理していますか?
- 開発者は、コードにシークレットを保存しないように理解するためのトレーニングを受けていますか？
- シークレットが特定された場合、パイプラインは停止されますか?
AWS Secrets Manager の動画
-
AWS Secrets Manager【AWS Black Belt】
-
Back to basics: Secrets Manager
-
AWS Secrets Manager Demo
料金
- AWS Secrets Manager の料金
- 30 日間の無料トライアルで、AWS Secrets Manager を追加費用なしで試すことができます
- 無料トライアルでは、30 日間、機密データのローテーション、管理、取得が可能です