この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本セッションについて
概要
AWS Secrets Manager is integrated with AWS managed databases to make it easy for you to create, rotate, consume, and monitor database user names and passwords. This chalk talk explores how client applications use Secrets Manager to manage private keys, API keys, and generic credentials. It also dives deep into secrets rotation.
スピーカ
-
Rushir Patel, WW Security Specialist, AWS
-
Steven Emelander, Software Development Manager, Amazon
セッションの内容
1. Generic credentials
- 資格証明を要求するJava Applicationがフロントエンド側にある
- 資格証明はSecrets Manager側で保存されていて、Java Applicationが起動する際、要求される。
- 開発者はハードコーディングする部分を減らせる
- 資格証明をディスクに保存する必要がない
2. API keys
- Web apllicationはAPIを通じて外部のサービスを呼び出す
- Client IDと Client secretと構成されている
- API keyはローカルに保存されない
- API keyが変わる場合、Secrets Managerの値は変わるのでデプロイをまたする必要はない
3. Private SSH keys
- 外部のサービスへS3バケットのログファイルを転送
- ログファイルを転送するLambda関数を作成、SSH private keyが必要
- SSH private keyはLambda関数に含まれなくてもいい
- もしSSH keyが変更される場合、Lambda関数を修正せずにSecrets Manager側で変更可能
- CloudTrailでSSH keyの使用を監視可能
4. Hybrid workloads
- AWSを使ってAWSのリソース及びデータベース資格証明を保存・管理
- AWS側のワークロードと同様のIAMロール・ポリシーを使ってAWSリソースに対しるアクセス可能
- AWSにアクセスするため、AWS Private CAまたは、Secrets Managerのような long-lived 資格証明を使用しなくてもいい
- Hardware モジュールを使わないのでコスト削減可能
5. Access token for 3rd party services
- AWSを使って他社のリソースに対するアクセストークンを保存・管理
- AWS Secrets Managerの４時間ローテーション機能を活用、アクセストークンのリフレッシュを自動化する
- ユーザーはアクセストークンを使ってリソースに対する作業を自動化するLambda関数を作成
- 資格証明の漏洩する時など起こられる危険を制限できる
- アクセストークンが必要なリソースに対して、自動で作業が始まるようにできる
最後に
本セッションを通じて、AWS Secrets Managerの５つのユースケースについて分かりました。
そしてSecrets Managerの４時間ローテーションやIAM anywhereなどの機能も分かって良かったです。
0
