AWSにおけるシークレット情報の取り扱い方と設定不備による脅威

デジタルペンテスト部の多羅尾です。

近年、ビジネスを展開する上でクラウドサービスは不可欠なものとなりました。クラウドサービスを利用するなかで、シークレット情報（データベースへの認証情報やサードパーティAPIキーなど）を適切に取り扱っていないと攻撃者にシークレット情報を取得されてしまい、情報漏えいやアカウントの不正利用などの被害に遭う危険性があります。

本記事では、AWS（Amazon Web Services）環境において、シークレット情報を適切に保護しておらず脅威に繋がる例と対策例としてAWSが提供している「シークレット情報を管理するサービス」を紹介します。

シークレット情報が取得される脅威例

脅威例として、Amazon ECS（Elastic Container Service）^※1とAWS Lambda^※2を取り上げます。これらのサービス上で、シークレット情報を平文で保管していた場合に発生し得るセキュリティリスクについてみてみます。

※1 Amazon ECSはAWSのコンテナオーケストレーションサービスで、コンテナのデプロイ、管理およびスケールが可能なサービスです。

※2 AWS Lambdaはサーバーレスコンピューティングサービスで、AWS Lambdaが対応するプログラミング言語で作成されたコードをアップロードするだけで、プログラム実行環境を用意することなくAWS上で実行できるサービスです。

脅威例：Amazon ECSの場合

コンテナ上で動作するアプリケーションに必要な設定情報は、環境変数を使って渡すことができます。

環境変数はAmazon ECSでも設定可能ですが、シークレット情報を平文で設定すると、環境変数への読み取り権限があれば、攻撃者も閲覧が可能な情報となっているため、シークレット情報が取得され不正に利用される可能性があります。図1では、Amazon ECSのタスク定義の環境変数にサードパーティAPIサービスのシークレット情報を平文で保存した際に発生する脅威を示します。

脅威例：AWS Lambdaの場合

アプリケーションのコード上にシークレット情報が平文で存在する場合、アプリケーションコードへの読み取り権限があれば、攻撃者も閲覧が可能な情報となっているため、シークレット情報が取得され不正に利用される可能性があります。

図2は、AWS Lambdaのコード上にサードパーティAPIサービスのシークレット情報を平文で保存した際に発生する脅威です。

対策

AWSでは、シークレット情報を管理するサービスとして、AWS Secrets Manager（以下、Secrets Manager）やAWS Systems Manager Parameter Store（以下、Parameter Store）があります。これらのサービスはシークレット情報を暗号化した上で保管できます。

図3にてSecrets ManagerやParameter Storeからシークレット情報を取得するまでの流れを示します。

Secrets Managerは有料のサービスですが、シークレット情報の自動ローテーション機能を提供しています。一方で、Parameter Storeは無料の基本機能（スタンダードパラメータ）を提供していて、アプリケーションの設定やシークレット情報を含むさまざまなパラメータを一元管理できますが、自動ローテーションはなく、手動で管理する必要があります。どちらのサービスを利用するかは、料金や自動ローテーションの可否などの項目を確認・検討するのが適切です。

Amazon ECSとAWS Lambdaは、Secrets ManagerおよびParameter Storeのどちらの利用も可能です。本記事では、Amazon ECSにSecrets Managerを利用し、AWS LambdaではParameter Storeを利用して対策後の結果を紹介します。

対策例：Amazon ECSの場合

Amazon ECSへの対策として、Secrets Managerを使用した結果をみてみます。Amazon ECSのタスク定義のシークレットで、Secrets Managerに保管したシークレット情報を指定することで、シークレット情報が保護されます。

なお、Secrets Managerにシークレット情報を保管する際、AWS KMS（Key Management Service）上の暗号化キーを使用して暗号化しますが、この暗号化キーへのアクセス権限を必要最小限に制限することで、許可されていないIAMユーザ・ロールからのシークレット情報の読み取りを保護できます。

図4にて、対策前と対策後のAmazon ECSのタスク定義の設定値を示します。これらの設定をすることで、シークレット情報を平文で記載することなく、シークレット情報が不要な読み取りから保護できます。

対策例：AWS Lambdaの場合

AWS Lambdaへの対策として、Parameter Storeを使用した結果をみてみます。Parameter Storeで暗号化を行う「安全な文字列（Secure String）」にシークレット情報を保管し、AWS Lambdaから保管したシークレット情報の階層パスを指定することで、シークレット情報が保護されます。

なお、Parameter Storeにシークレット情報を保管する際、AWS KMS上の暗号化キーを使用して暗号化しますが、この暗号化キーへのアクセス権限を必要最小限に制限することで、許可されていないIAMユーザ・ロールからのシークレット情報の読み取りを保護できます。

図5にて、対策前と対策後のAWS Lambdaのコードを示します。これらの設定をすることで、シークレット情報を平文で記載することなく、シークレット情報が不要な読み取りから保護できます。

さいごに

本記事では、AWSにおけるシークレット情報の取り扱いについて紹介しました。

AWS上に平文でシークレット情報があると、権限を持つ攻撃者によりシークレット情報が読み取られ、情報漏えいやアカウントの不正利用などにつながる可能性があります。これらの脅威を防ぐために、Secrets ManagerやParameter Storeを使用してシークレット情報を暗号化し、アクセス権限を必要最小限に制限することを推奨します。本記事が、お役に立てれば幸いです。