AWS Systems Manager Parameter StoreとSecrets Managerのどちらを使うべきか

AWSデベロッパーアソシエイト試験の勉強をしていたときにSystems Manager Parameter StoreとSecrets Managerの問題がでてきて気になったので少し調べてみました。

一番の疑問としては、「何が違うの??」ということでした。 同じ疑問をもった人の良記事やAWS公式のFAQがあったので、そちらを紹介していきます。

結論

AWS公式のFAQの回答が一番わかりやすかったので引用します(よくある質問 - AWS Systems Manager)。

どちらを使うべきか?

設定とシークレットにひとつのストアが欲しい場合、パラメータストアをお使いください。ライフサイクル管理を備えたシークレット専用のストアが欲しい場合、シークレットマネージャーをお使いください。

追加して説明しておくと、

  • 「設定とシークレットにひとつのストアが欲しい場合」というのは、パラメータストアは様々なAWSサービスで利用できる一方で、シークレットマネージャは利用できる場所に若干制限があるからだと思われる。
  • 「ライフサイクル管理を備えた」というのは、シークレットマネージャーはシークレットのローテーション、監査をおこなうことができます。

「セキュリティの違いはないの?シークレットマネージャーの方がセキュリティ性が高そう」と思うかもしれないが、セキュリティに関する違いはない

Q: Parameter Store と Secrets Manager のセキュリティモデルには違いはありますか? ありません。シークレットマネージャーとパラメータストアは両方とも同じように安全です。これらのサービスは両方ともカスタマーの所有する KMS キーを用いて保管中の暗号化をサポートしています。

比較表

Qiitaの記事に比較表があり、2019年5月までは更新情報が書かれていました。 その表をパクってきて情報を更新したものが下表になります。

比較項目 Parameter Store Secrets Manager
情報の保管単位 /dev/os-usersのような階層型のパラメータに保管可能(db-stringという同じパラメータ名を dev/db-stringprod/db-stringなどの異なる階層パスで使用できる)。パラメータにはタグ付け可能。
(※1次の文について後述)パラメータには1つまたは複数の値を保管可能。パラメータと値は1:1または1:n。
dev/db-stringのような階層型のシークレットに保管可能。シークレットには、1つまたは複数の「キーと値のペア」を保管可能。シークレットにはタグ付け可能。
(※次の文について後述)シークレットと、「キーと値のペア」は1:1または1:n
保管された情報の暗号化 暗号化され、KMSに保存 暗号化され、KMSに保存
保管された情報へのAPIアクセス 可能 可能
APIアクセス時のRate limit 最大1000 Req/Sec 10000 Req/sec ※DescribeSecret、GetSecretValueの場合(参照)
保管された情報へのアクセス制御 IAMポリシーで制御可能 IAMポリシーで制御可能
連携可能なAWSサービス 多数(参照) RDS for MySQLPostgreSQL、Auroraの認証情報保存を標準サポート(Secrets Managerの設定画面上で、対象のRDSを選択可能)。AWS CLISDKを通じてEC2やECS、Labmda等と連携可能。
保管された情報のバージョニング 複数バージョンを保持可能。1パラメータにつき100(参照)。ラベルをつけて管理可能。クラスメソッドの参考記事 複数バージョンを保持可能。Secrets Managerの内部的には1シークレットにつき約100保持可能だが、バージョンに付与できるラベルの最大数は20(参照)。バージョンとラベルの関係性については、クラメソさんのブログが詳しい。
保管された情報の使用状況の監査・監視 CloudTrail、CloudWatch、SNS、EventBridgeを活用して監査・監視可能。 CloudTrail、CloudWatch、SNS、EventBridgeを活用して監査・監視可能。AWS Artifactを使用して、サードパーティの監査レポートを出力するなど、コンプライアンスを監査することも可能。
シークレット情報の自動更新 パラメータ種別アドバンスド(※2後述の段落にて)であれば、EventBridge、Lambdaなどと組み合わせることで対応可能。ただし、自動更新するならばSecrets Managerを利用すべき。 RDS for MySQLPostgreSQL、Auroraの認証情報自動更新を標準サポート。その他DBの接続情報やAPIキー等は、Parameter Storeにて提供されるLambdaスクリプトをカスタマイズすることで対応可能。
利用料金 パラメータ種別スタンダードは無料。但し、暗号化に利用されるKMSにてCMK(カスタマーマスターキー。ユーザ側で生成したキー)を利用する場合、KMSのAPI呼び出し料金が必要。パラメータ種別アドバンスドは有料(パラメータあたり0.05 USD/月)。 料金詳細はこちら 有料。シークレット1件あたり 0.40 USD/月。10,000回のAPIコールあたり0.05 USD。料金例はこちら。更に、Parameter Storeと同様、KMSの暗号化にCMKを利用する場合、KMSのAPI呼び出し料金が必要。

※1パラメータストアの「パラメータには1つまたは複数の値を保管可能。パラメータと値は1:1または1:n。」および、Secrets Managerの「シークレットと、「キーと値のペア」は1:1または1:n」は、AWSの公式ガイドなどを確認したが記述を見つけることができませんでした。そもそもそのようなことが可能なのか、値の取得で困りそうですが。

AWS Systems Manager Parameter Store アドバンスド

比較表の※2である、パラメータ種別アドバンスドについてまとめておきます。 パラメータストアにはスタンダードという追加料金なしのパラメータ種別のほかに、アドバンスドというパラメータ種別が存在します。 アドバンスドは、

  • 追加料金がかかるようになり、
  • 利用できるパラメータの数が多くなり、
  • パラメータの値の最大サイズが大きくなり、
  • パラメータポリシーを使うことができ、
  • API呼び出しのスループットには変更はない

AWSの公式情報から比較表をもってきました。

スタンダード アドバンスド
許可されるパラメータの合計数(AWSアカウントおよびAWSリージョンあたり) 10,000 100,000
パラメータ値の最大サイズ 4 KB 8 KB
パラメータポリシーの使用可否 いいえ はい
詳細については、「パラメータポリシーの割り当て」を参照してください
Cost 追加料金なし 料金対象
詳細については、AWS Systems Manager 料金を参照してください。

ちょっとした注意点として、パラメータの種別をスタンダードからアドバンスドに変更することは可能だが、反対は実施することができません。なぜならば、アドバンスドからスタンダードへの変更はパラメータのサイズを切り捨てる必要があるからです。 ちょっとお試しで変更してしまうと戻せないので、パラメータを削除・新規作成が必要になります。

パラメータポリシー

スタンダードとアドバンスドの違いとして、パラメータポリシーという機能があります。 パラメータポリシーとは、特定の条件でパラメータを操作することができる機能です。

パラメータポリシーは3つのタイプが存在し、ExpirationExpirationNotificationNoChangeNotificationとなっています。

注目したいのは、NoChangeNotificationです。このパラメータストアは指定された期間内にパラメータが変更されていない場合、Amazon EventBridgeでのイベントを開始できます。これは、Amazon EventBridgeでパラメータストア(パラメータストアをイベントソースとする、定義したスケジュールなどではなく)からのイベントを受け取り、そこから別のサービスを起動できるようになります。よって、パスワードローテーションもどきを実装できる気がするが、AWSとしては、そのようなことはせずにシークレットマネージャを使うことを推奨しています。

参考文献