この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS Summits 2018 | San Franciscoにて突如発表された、AWS Secrets Manager。自分も速報記事（【完全新機能】DB認証情報やOAuthキーを一元管理可能なAWS Secrets Managerが発表されました！）書いて以降、あれこれ触ってみています。
この記事では、これからAWS Secrets Managerを触ってみようという人に向けて、公式ドキュメントの内容を中心に、その概要と動作原理、各種チュートリアル、詳細を学ぶためのリソースをまとめてみました。
とりあえず読んでおいてもらえれば、幸せになれるかと思っております。
目次
- 各種リソース
- AWS Secrets Managerとは？
- AWS Secrets Managerの主要機能3点
- AWS Secrets Managerの動作原理
- AWS Secrets Managerのローテーション機能詳細
- 利用料金
- 手を動かして学ぶには何が良いか？
- 運用上の推奨事項（ベストプラクティス）
- AWS Systems Manager パラメータストアとの違いは？
__ （祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 AWS Secrets Managerﾀﾞﾜｯｼｮｲ |_|＿| し'´Ｊ
各種リソース
製品概要はこちらから。トップページは既に日本語化されています。
AWSドキュメントの入り口はこちら。
AWS コンソールにはこちらからアクセスできます。
Developers.IOにも「AWS Secrets Manager」カテゴリーが爆誕しております！是非こちらも、参照ください。
AWS Secrets Managerとは？
AWS Secrets Managerは、AWS内リソース、オンプレミス環境、またはサードパーティアプリケーションにアクセスするための各種機密情報の管理を、簡単にするAWSのマネージド・サービスです。AWS CLI、API、SDKを利用してこれらの機密情報へのアクセス、および制御が可能です。
例えば、DBから情報を取得するアプリケーションの場合、アプリケーションにDBアクセスのための資格情報を埋め込む必要があります。この資格情報をローテーションさせる場合、資格情報の更新とともに各アプリケーションへの配布が必要となります。
代わりに、AWS SecretsManagerを利用すると、ハードコードされていた機密情報を、都度のAPI呼び出し処理に置換できます。機密情報がアプリケーションに存在せず、さらに機密情報を一定間隔でローテーションさせることで、セキュリティリスクを大幅に削減できます。
AWS Secrets Managerの主要機能3点
主要機能①：機密情報を保持するのではなく、アプリケーションで都度取得
AWS Secrets Managerを利用する最も重要な理由は、アプリケーション内のハードコードされた機密情報を削除することにあります。また、機密情報の利用が古く更新必要性を感じた時の、更新の手間を軽減します。
機密情報は、履歴を保つ場合もあり、バージョン管理することで、機密情報を複数保持することも可能です。これは、ステージングラベルという機能を利用して実現しています。
主要機能②：多様な機密情報を格納可能
機密情報は、任意のJSONテキストで格納できます。データ部分には、最大4096バイトのテキストを格納可能。
- サーバー名
- IPアドレス
- ポート番号
- データベース接続情報
- 各種APIキー
各機密情報は、AWS Key Management Serviceで暗号化されます。また、AWS KMSカスタマーマスタキー（CMK）にも対応しています。
主要機能③：ローテーション機能の実装
スケジュールに基づいた機密情報のローテーションに対応しています。これはAWS Lambdaファンクションによって定義され、機密情報のバージョン管理にも利用されます。
下記データベースは、機密情報のローテーションとデータベース接続情報のローテーションが統合されています。
- Aurora
- RDS（MySQL）
- RDS（PostgreSQL）
その他のデータベースについては、ローテーション機能の独自実装が必要となります。
AWS Secrets Managerの動作原理
機密情報の基本構造はこうなっています（公式ドキュメントより引用）
上段、青枠がメタデータ。下段、灰色枠がバージョン情報です。
メタデータ
メタデータには以下の情報が含まれます。
- 機密情報の名前、説明、ARN
- 暗号化および復号化に利用するAWS Key
- ローテーション頻度と、ローテーションに利用するLambdaファンクションの情報
- タグセット
バージョン情報
バージョン情報の特徴は以下の通り。
- 機密情報変更時は、新バージョンが作成される
- 各バージョンには、暗号化された値のコピーが保持される
- 各バージョンには、機密情報がローテーション上のどこにあるかを識別するステージングラベルが添付される
バージョン機能に関しては、その動作を弊社菊池が詳細に検証しています。
その他、ローテーション、バージョン、ステージングラベルの詳細は、公式ドキュメントをご参照ください。
AWS Secrets Managerのローテーション機能詳細
AWS Secrets Managerの主要機能であるローテーション機能について、詳細は下記より確認することができます。
AWS Secrets Manager シークレットの更新 - AWS Secrets Manager
シークレット情報の更新時に最も重要なのは、シークレット情報切替時のアプリケーション側におけるダウンタイム。公式ドキュメントでは、ローテーション方式について、大きく２つの方法が紹介されています。
ローテーション方式1「1つのユーザーとパスワードを利用してローテーションする方式」
1 つのパスワードのみを使用してシングルユーザーの AWS Secrets Manager シークレットを更新する - AWS Secrets Manager
この場合、シークレット情報のローテーション中に古いシークレット情報でアプリケーション側からアクセスされた場合、サービスへのアクセスが不能となります。パスワードを変更したsetSecretフェーズとfinishSecretフェーズの間でこのエラーが起こった時の対処が何かしら必要であれば、アプリケーション側には最低限の再試行機能が必要となります。
ローテーション方式2「２つのユーザーを切替える方式」
既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する - AWS Secrets Manager
この場合、旧シークレット情報のDBユーザーと同等の権限をもつDBユーザーを新らしく用意しておくことで、シークレット情報切替時のダウンタイムを防ぎます。具体的には、新シークレット情報をAWSCURRENTラベルに切替えた時、旧シークレット情報にはAWSPREVIOUSラベルを付与しておくことで、シークレット情報切替時の復旧手段として保持しておきます。新しいシークレット情報を利用するようにアプリケーション側が全て切り替わったタイミングで、旧ラベルを全て破棄し、認証情報のローテーションを完了させます。
このためには、ローテーション設定で作成されたLambda関数に対して、カスタマイズが必要となります。詳細は、2 人のユーザー間でのみ切り替えるようにローテーションを設定するを参考にしてください。
利用料金
非常にシンプルです。
Pricing | AWS Secrets Manager | Amazon Web Services (AWS)
- PER SECRET PER MONTH
- $0.40 per secret per month
- PER 10,000 API CALLS
- $0.05 per 10,000 API calls
1つあたり月額$0.40は非常に安価だと思うのですが、1万APIコールで$0.05は、使い方によっては注意が必要な料金設定かもしれません。
手を動かして学ぶにはなにが良いか？
公式ドキュメントにチュートリアルが用意されています。
Developers.IOにも、基本設定とDBパスワードローテーションについて記事がありますので、こちらもよろしければ参照ください。
- 新サービス「AWS Secrets Manager」をチュートリアル2種（基本設定、RDSローテーション）で基礎から学ぶ ｜ Developers.IO
- 機密管理サービス AWS Secrets Manager で RDS のパスワードローテーションを試す ｜ Developers.IO
運用上の推奨事項（ベストプラクティス）
AWS Secrets Managerを運用する上での推奨事項です。
追加の機密情報も保護する
保護したい機密情報には、一般的にユーザー名とパスワード以外にも、データベース、サービス、パスワードヒント、接続先トークンなど、様々なものが含まれます。それらの情報もあわせて、シークレット情報に含めるようにしてください。
シークレット情報は、SecretString、またはSecretBinaryフィールドのいずれかに格納できます。最大4096文字まで入力できるので、自由に使ってください。
シークレット情報のJSON例を下記に記します。
{
"username": "saanvisarkar",
"password": "i29wwX!%9wFV",
"host": "http://myserver.example.com",
"port": "1234",
"database": "myDatabase"
}Lambdaのロギングとデバッグのリスクを軽減する
Secrets Managerのカスタムラムダローテーションファンクションを作成するときは、機密情報が、そのロギングステートメントやデバッグ用処理に含まれないように十分注意してください。デバッグ処理は、それらの機密情報をCloudWatch Logsに書き込む可能性があります。
もし、開発中にそれらの処理をコードに埋め込んだ場合は、プロダクション環境で使用する前に必ずコードから削除するようにしてください。
CLIを利用した機密情報の保管リスクを軽減する
AWS CLIなどを利用して機密情報にアクセスする場合、WindowsコマンドプロンプトやPowerShell、Linux Bashなどを利用することが多いと思いますが、これらターミナルの便利機能により、第3者が機密情報にアクセスする危険性があります。
例えば、殆どのシェルでは、矢印キーの上で過去のコマンドを入力できます。また、バックグランドで動作するユーティリティでは、コマンド・パラメータにアクセスできます。また、ターミナルに表示された内容を自動的にロギングできるアプリケーションもあります。
これらのリスクを軽減するために、以下を検討してください。
- コンソールから離れるときは、常に端末をロックする
- 不要になったコンソールユーティリティをアンインストールする
- シェルとリモートアクセスプログラムが、入力したコマンドをロギングしないようにする
- シェルのコマンド履歴で取得されないパラメータを利用する
例えば、テキストファイルにシークレットテキストを入力し、AWS Secrets Managerに渡してすぐに破棄する方法を示します。
$ touch secret.txt # Creates an empty text file
$ chmod go-rx secret.txt # Restricts access to the file to only the user
$ cat > secret.txt # Redirects standard input (STDIN) to the text file
ThisIsMyTopSecretPassword^Z # Everything the user types from this point up to the CTRL-Z (^Z) is saved in the file
$ aws secretsmanager create-secret --secret-id TestSecret --secret-string file://secret.txt # The Secrets Manager command takes the --plain-text parameter from the contents of the file
$ shred -u secret.txt # The file is destroyed so it can no longer be accessed.AWS Systems Manager パラメータストアとの違いは？
これは完全に自分の私見です。似たような使い方ができそうな既存サービスに、AWS Systems Manager パラメータストアがありますが、根本的に以下の点が違うのではないでしょうか。
- ローテーションの実装
AWS Secrets Managerの思想としては、機密情報をアプリケーションに保持させないだけではなく、その更新についての仕組みとして、バージョン管理機能と共にローテーション実装（Lambda）が組み込まれている点かと思います。パラメータストアにもバージョニング機能はありますが、AWS Secrets Managerのローテーション機能を有効にすると、合わせてLambdaが作成されるので、其の中を自由にカスタマイズすることにより、幅広いユースケースに対応できます。
内部的にパラメータストア利用しているかと思っていたのですが、そんなことは無く、AWS Secrets Manager独自で管理されているようです。
まとめ
以上、AWS Secrets Managerの全体的な特徴と設計思想、各種リソースをまとめてみました。
ローテーション機能の利用には、プロダクション環境での運用前に十分な事前検証をオススメします。しかし、一度運用に乗り複数システムで稼働させることができれば、機密情報の管理・運用に非常に有用な手段になり得るサービスではないでしょうか。今後の進化に非常に注目ですね。
今後もアップデートがあった際には更新情報をお知らせするとともに、こちらの記事も随時アップデートしていきます。
それでは、今日はこのへんで。濱田（@hamako9999）でした。
12
