AWS Secrets Managerの導入・構築のポイント
はじめに
こんにちは！株式会社SHIFTでインフラアーキテクトをやっているHORIEです。
業務の中で、AWSの認証情報を管理するマネージドサービスである、「AWS Secrets Manager(以下、Secrets Managerと記載）」を利用する機会がありました。Secrets Managerの導入の検討、及び、Secrets Managerの構築・動作検証をする中で様々な学びを得られたため、今回はそのノウハウについて書いていきたいと思います。
Secrets Managerの導入を検討する際に、また、環境構築でうまくいかない時のトラブルシューティングの際の一助になると幸いです。
AWS Secrets Managerとは
AWS Secrets Managerは、データベースのパスワードやAPIキーなどのデータ流出の可能性がある認証情報（シークレット）を集約し、管理するサービスです。
これを利用することで、アプリケーションに認証情報を直接記載することなく、Secrets ManagerにAPIアクセスしてパスワードを取得するため、認証情報をセキュアに管理することができます。
SSM Parameter Storeとの比較
AWSには、AWS Secrets Managerと似たパスワード管理機能を持ったサービスとしてAWS Systems Manager Parameter Store（以下、SSM Parameter Storeと記載）があり、よく利用の際に比較対象となります。下記が2つの比較した表です。
ユースケース
上記比較を考慮し、各サービスの代表的な使い分けは以下のようになるかと思います。
AWS Secrets Manager：シークレット管理に特化しているため、Lambdaと連携したパスワードのローテーションも行うことができることが最大の特徴。
また、セキュリティ標準(PCI DSS,HIPPA等）の準拠。そのため、システムのセキュリティ要件で認証情報の定期ローテションやセキュリティ標準への準拠が必要な場合に利用
SSM Parameter Store：シークレット以外のアプリケーションの可変パラメータの外部ストアとして扱うことができるため、アプリケーションのパラメータと一緒にシークレット情報も管理したい場合に利用
今回は担当プロジェクトのセキュリティ要件として、認証情報の定期的な変更があったため、AWS Secrets Managerを選択しました。
Secrets Managerの利用方法
1.構築時の構成
今回の構成は下記のような構成で作っています。
WEBAPサーバ(EC2)とLambdaをコンピューティング用のプライベートサブネットに、DBとしてRDS(Orale)をDB用プライベートサブネットに配置（実際はEC2/RDSはMulti-AZの冗長ですが図としては割愛）
シークレット管理にSecrets Managerを使用
KMSで作成したCMK(カスタマーマスターキー）によりRDSを暗号化
コンピューティング用のサブネットにSecrets ManagerのVPCエンドポイントを配置
Secrets Manageの挙動としては、下記のようになります。
RDSアクセス時（構成図の赤矢印）
WEBAPサーバ(EC2)がSecrets Managerに認証情報を取得し、その認証情報をもとにRDSにアクセスを実施
RDSのパスワード変更時（構成図の青矢印）
LambdaがSecrets Managerに認証情報を取得し、その認証情報をもとにRDSにパスワードのローテーションを実施
2.作成方法
作成方法は、AWSコンソールからSecrets Managerを画面通り設定すればできるため、今回は省略します。詳細は下記のAWS公式チュートリアル等を参考にしてください。
https://docs.aws.amazon.com/ja_jp/secretsmanager/latest/userguide/create_secret.html
パスワードの定期ローテションが必要な場合は、Lambdaを利用する必要があります。ローテション用のLambdaはSecrets Manager作成する中で、「関数の作成」を選択すればAWS側で作成してくれるため、コーディングは不要になります。
ただし、必要に応じて配置するVPC/サブネットやセキュリティグループ、IAMロールなどは修正する必要があります。
3.作成のポイント
作成自体はさほど難しくありませんが、暗号に伴う権限やVPCエンドポイントなどのアクセス制御が正しく設定されていないと、認証情報を取得できなかったり、シークレットのローテーションが失敗します。私の場合も何回かうまくいかないケースがあったため、ポイントを下記に記載します。
うまくいかない場合のチェックリストとして利用いただければ幸いです。
①Secrets Managerへのリソースアクセス権限（下記どちらかが設定されているか）
Secrets Managerのアクセス許可設定に、WEBAPサーバとLambdaのIAMロールがあるか
WEBAPサーバとLambdaのIAMロールに、Secrets Managerへのアクセス権限を持つIAMポリシーがあるか
②CMK(KMS)へのリソースアクセス権限（下記どちらかが設定されているか）
CMK(KMS)のキーユーザーに、WEBAPサーバとLambdaのIAMロールがあるか
WEBAPサーバとLambdaのIAMロールに、KMSへのアクセス権限を持つIAMポリシーがあるか
③SecretManagerのVPCエンドポイントへのアクセス許可
SecretManagerのVPCエンドポイントのセキュリティグループに、WEBAPとLambdaのセキュリティグループ（もしくはサブネット）からのHTTPSのアクセス許可があるか
④RDSへのアクセス許可
RDSのセキュリティグループに、WEBAPとLambdaのSGからのDBポート(Oracleの場合は1521)のアクセス許可があるか
4.まとめ
AWS Secrets Managerは、シークレット管理に特化したサービスであり、Lambdaと連携したパスワードのローテーションも行うことができることが最大の特徴
構築の際には、アクセス権限(IAMもしくは各サービスのポリシー設定）やアクセス制御（セキュリティグループ）を正しく設定するのがポイント
5.参考文献
執筆者プロフィール：N HORIE
国内大手システムインテグレーターにて主にテレコム業界、製造業向けの海外プロジェクトのインフラ領域のSE、PL/PMとして従事した後、SHIFTにジョイン。
SHIFTでは、主にAWSやIaCに関するインフラアーキテクトとしてプロジェクトを推進している。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/