プログラムからのアクセス利用時に AWS アカウントを保護するためのガイドライン

AWS を利用する際に最も重要なこととして、AWS リソースのセキュリティの確保があります。誰にリソースにアクセスさせるのか、注意深くコントロールする必要があります。これは、AWS ユーザーがプログラムを使ったアクセスをしている場合にも同様です。プログラムからのアクセスは、自社で作成したアプリケーションもしくはサードパーティーのツールから AWS リソースにアクションすることを実現します。AWS サービス側でアクセスリクエストを認可させるためにアクセスキー ID とシークレットアクセスキーを使ってリクエストに署名することが可能です。このようにプログラムによるアクセスは非常にパワフルなため、アクセスキー ID とシークレットアクセスキーを保護するためにベスト・プラクティスを活用することが重要です。これは不意のアクセスあるいは悪意のあるアクテビティビティからアカウントを保護するために重要です。この投稿では、いくつかの基本的なガイドラインを提示し、アカウントを保護する方法を示します。また、プログラムからの AWS リソースへのアクセスを行う際に利用出来るいくつかの方法を提示します。

ルートアカウントを保護する

AWS のルートアカウント – AWS にサインナップするときに最初に作られるアカウント – は全ての AWS のリソースに無制限でアクセス出来ます。ルートアカウントには権限による制御が効きません。したがって、AWS はルートアカウントに対してアクセスキーを作成しないように常におすすめしています。アクセスキーを与えると利用者がアカウント全体を廃止するような強力な権限を得てしまいます。ルートアカウントにアクセスキーを作成するかわりに、利用者は個別の AWS Identity and Access Management（IAM）ユーザーを作成して利用することができます。さらに、最小権限の考え方に従い、それぞれの IAM ユーザーに対してタスクを実行するのに必要な権限のみを許可します。複数の IAM ユーザーの権限を簡単に管理するために、同じ権限を持つユーザーを IAM グループにまとめる方法も使えます。
ルートアカウントは常に多要素認証（MFA）で保護するべきです。このセキュリティに関する追加の保護は許可されていないログインからアカウントを保護することに役立ちます。多要素認証とは、認証に複数の要素を使うことで、パスワードのような知識認証要素と、MFA デバイスのような所有物認証要素を同時に使うことです。 AWS はバーチャルとハードウェアの両方のMFA 用のデバイス、さらに U2F セキュリティキーを多要素認証用としてサポートしています。

AWS アカウントに対するアクセスを許可するときの考え方

ユーザーに AWS マネジメントコンソールやコマンドラインインターフェース（CLI）にアクセスを許可するには２つの選択肢があります。１つ目は、IAM サービスによって管理されるユーザー名とパスワードでログインする ID を作ることです。もう１つは、IDフェデレーションを利用して、既に企業の中に存在する認証情報を使って AWS コンソールや CLI にログインさせることです。それぞれのアプローチには異なるユースケースがあります。フェデレーションは、既に集中管理されたディレクトリがあるか、現在の制約である5000人以上の IAM ユーザーを作る必要性が計画にある場合に良い選択肢になります。
注釈 : AWS アカウントへのアクセスは AWS IAM サービスによって管理されます。上記のどちらの選択肢を取った場合にも、IAMのベストプラクティスをよく読んで頂き、従うようにしてください。

どのようなケースでアクセスキーを使うかを決定する

AWS 環境の外側で実行されているアプリケーションは、AWS リソースにプログラムを介してアクセスする際にアクセスキーが必要です。例えば、オンプレミス環境で実行されている監視ツールやサードパーティ製の自動化ツールがアクセスキーを必要とします。
しかしながら、プログラムを介したアクセスが AWS 環境の中で必要な場合には、ベストプラクティスとしては、アクセスキーではなく IAM ロールを使うこととなります。IAM ロールは設定された権限の組み合わせです。特定のユーザーやグループには紐づけされません。そのかわりに、信頼されたエンティティが特定のビジネスタスクを実行するためにロールを引き受けることが出来ます。
ロールを使うことで、アクセスキー ID やシークレットアクセスキーをハードコードすることなく、リソースへのアクセスを許可することが可能になります。例えば、Amazon Elastic Compute Cloud（EC2）インスタンスに Amazon Simple Storage Service（Amazon S3）バケットへのアクセスを許可するために、バケットへのアクセスを EC2 インスタンスに許可するポリシーを持つロールを作成しアタッチすることが出来ます。このアプローチは IAM サービスが動的に認証情報を管理し管理者が一時的な認証情報を自動ローテーションすることでセキュリティを向上させます。

サービスアカウントに対する最小権限の付与

サービスアカウント（AWS の外側で実行されるアプリケーションによるプログラムアクセスのためのアカウント）を作る、またアクセスキーをこのアカウントのために作成する場合、それぞれのユースケースのために個別のサービスアカウントを作るべきです。このアプローチにより特定のユースケースに必要な最小限の権限に制限することが可能になります。たとえ認証情報が漏れたとしても影響範囲が拡大することを防げます。例えば、監視ツールとリリース管理ツールの両方が AWS 環境へのアクセスが必要だったとします。この場合は２つのサービスアカウントを作成して、それぞれのツールが使う最小限の個別のポリシーを適用します。
以上のアプローチに加えて、それぞれのポリシーでさらに制限されたアクセスになるように条件をつけることもベスト・プラクティスとなります。例えば、特定の IP アドレスからのクライアント接続しか許可しないような条件です。

以下に、最小権限を実装したポリシーの例を示します。このポリシーは必要な権限（PutObject）を特定のリソース（”examplebucket” という S3 バケット）に許可しています。さらに、クライアントは特定の IP 範囲（203.0.113.0/24）のみに制限しています。


{
    "Version": "2012-10-17",
    "Id": "S3PolicyRestrictPut",
    "Statement": [
            {
            "Sid": "IPAllow",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::examplebucket/*",
            "Condition": {
                "IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
            } 
        } 
    ]
}

AWS STS サービスによる一時的な認証情報の利用

AWS Security Token Service （AWS STS）は一時的な認証情報をプログラムコードや AWS CLIやサードパーティーツールで使うためにリクエストを送ることが出来る Web サービスです。このサービスにより信頼関係がある IAM ロールを引き受けることが可能になります。また、有効期限がある認証情報をロールに紐付いた権限付きで生成することができます。これらの認証情報は有効期限までしか使えないため、リスクが下がります。
一時的な認証情報は2つの方法で作ることが出来ます。AWS CLI から作る方法は、自分のマシンでテストしたり、オンプレミスやサードパーティーツールからテストする際に有用です。また、AWS SDK を使いプログラムコードから生成することも可能です。こちらのアプローチは、アプリケーションコードの中で認証情報が必要な場合や、異なる複数の権限レベルを必要とする複数のユーザーが必要な場合に有効です。

AWS CLI を使った一時的な認証情報の作成

AWS CLI にアクセス可能な場合、ローカル環境でのテストやサードパーティーのツールで使うために一時的な認証情報を生成するために使うことが出来ます。このアプローチの前提として以下の3つが必要です。
・AWS CLI にプライマリーユーザーアカウントかフェデレーション経由でアクセス出来る環境。IAM 認証情報で CLI アクセスを構成する方法はこちらをご覧ください。フェデレーションを使う場合はこちらのブログ記事の操作方法が参考になります。
・IAM ロールテストクライアントに必要な権限を持っているものが必要です。例えば、下記の図で “s3-read”という IAM ロールを使っています。このロールはこのユースケースに必要な最低限の権限を適用したポリシーのみを持つべきです。
・ユーザーアカウントとサービスロール（“s3-read”）の間の信頼関係。これはサービスロールを引き受け、一時的な認証情報を作成するのに必要です。信頼関係の作成方法はこちらのリンクを参照してください。

以下のコマンドの例では 15 分間有効なテンポラリーのアクセスキー ID とシークレットアクセスキーを ”s3-read” というロールに紐づけた権限をもとに作成します。アカウントナンバーやサービスロール、有効期限を置き換えて皆様で使って頂くことが可能です。置き換えたコマンドを実行するとローカルクライアント環境でシークレットアクセスキーとアクセスキー ID を使うことが可能になります。

aws sts assume-role --role-arn <arn:aws:iam::AWS-ACCOUNT-NUMBER:role/s3-read> --role-session-name <s3-access> --duration-seconds <900>

コマンドの実行結果

{ "AssumedRoleUser": 
    { 
        "AssumedRoleId": "AROAIEGLQIIQUSJ2I5XRM:s3-access", 
        "Arn": "arn:aws:sts::AWS-ACCOUNT-NUMBER:assumed-role/s3-read/s3-access" 
    }, 
    "Credentials": { 
        "SecretAccessKey":"wZJph6PX3sn0ZU4g6yfXdkyXp5m+nwkEtdUHwC3w",  
        "SessionToken": "FQoGZXIvYXdzENr//////////<<REST-OF-TOKEN>>",
        "Expiration": "2018-11-02T16:46:23Z",
        "AccessKeyId": "ASIAXQZXUENECYQBAAQG" 
    } 
  }

プログラムコードから一時的な認証情報を作成する

AWS SDK を使っているアプリケーションがある場合、認証情報をハードコードすることなく、AWS STS サービスを使って一時的な認証情報をプログラムコードから作ることが可能です。このアプローチは認証情報が必要なクライアント側で実行されるコードがある場合や、複数のユーザータイプが必要な場合（例えば、管理者、パワーユーザー、一般ユーザーなど）に推奨されます。複数のユーザータイプの認証情報をプログラムコードにハードコードしなくて済むからです。
AWS SDK で一時的な認証情報を使う方法をさらに詳しく知りたい場合にはこちらのリンクにアクセスしてください。

アクセスアドバイザーを利用する

IAM コンソールは AWS サービスがどのプリンシパルで最後にアクセスされたかという情報を表示出来ます。この機能は、サービスの最終アクセス時間データの表示と呼ばれます。
この機能を使うと IAM ユーザー、グループ、ポリシーごとに最後にいつサービスにアクセスしたかが分かります。この情報ともとに、剥奪する、もしくは制限を加えるほうが良い権限を特定することが可能です。
この機能を定期的なセキュリティチェックの一部として使ってください。IAM のエンティティが持つ権限のレビューと不要になった権限の削除に有用です。また、アクセスアドバイザー API を使うことで自動かつ定期的な権限のレビューをすることも可能です。この API についての詳しい情報はこちらのブログ記事を読むことをおすすめ致します。

認証情報管理のための他のツール

最小権限の原則に従ったアクセスと一時的な認証情報の利用が重要であるのと同様に、利用者が自分の認証情報を定期的にローテーションしたり、ストレージに適切に保管するのも重要です。下に挙げるツールは、安全に認証情報を保管したり、取り出したり、ローテーションするのに役立つサービスや機能になります。

AWS Systems Manager Parameter Store

AWS Systems Manager Parameter Store は、AWS アカウント全般に渡って設定と機密情報を安全に集中管理するためのストレージを提供します。平文あるいは暗号化された構成パラメータや認証情報、ライセンスキーを格納出来ます。格納されたデータに対して誰がパラメータにアクセス出来るかという詳細なアクセス制御をかけられます。これによりデータ保護に対するセキュリティ層を追加出来ます。
パラメータストアは、アカウントの構成データ管理を階層化されたストレージで管理したい場合に良い選択です。パラメータストアにデータベースアクセス認証情報（ユーザー名とパスワード）を格納して、AWS Key Management Service で管理された暗号鍵で暗号化することが出来ます。また、アプリケーションが稼働している EC2 インスタンスに許可を与えてこの認証情報を復号してから読みとることが可能です。
AWS System Manager Parameter Store についての詳細はこちらのリンクを参照してください。

AWS Secrets Manager

AWS Secrets Manager は組織で使われているシークレットのライフサイクルを集中管理することが出来ます。ライフサイクルにはローテーション、監査、アクセス制御が含まれます。自動的なシークレットのローテーションを行うことで、Secrets Manager はセキュリティやコンプライアンスの要件を満たします。Secrets Manager はまた MySQL、PostgreSQL,、Amazon Aurora、Amazon RDSなどのサービスとのビルトインインテグレーションを提供し、他のサービスにも拡張可能です。

AWS Secrets Manager に関する更に詳細な情報はこちらのリンクをご覧ください。

Amazon Cognito

Amazon Cognito はユーザー登録、サインイン、アクセス制御の機能を Web アプリケーションやモバイル・アプリケーションに追加します。
Cognito は ID プロバイダ（IdP）として使うことが出来ます。アプリケーションのためにユーザーと認証情報を安全に格納し、運用することが可能です。また、OpenID Connect や SAML、Amazon.com のような著名な Web アイデンティティプロバイダとインテグレートすることが可能です。
Amazon Cognito を使うことで、利用者に AWS サービスにアクセスする一時的な認証情報を生成し、クライアントアプリケーションで長期間有効な認証情報を保持しないように制限することが可能です。
IdP としての Amazon Cognito の更に詳細な情報は、Amazon Cognito ユーザープールの開発者ガイドのサイトを御覧ください。Amazon Cognito のサードパーティー IdP との連携については、Amazon Cognito IDプールのガイドをご覧下さい。

AWS Trusted Advisor

AWS Trusted Advisor は AWS アカウントのリアルタイムチェック機能を提供すると共に、コスト削減やパフォーマンス向上、信頼性の向上、セキュリティレベルの向上のためにリソース最適化をどのように実施すれば良いかをガイドしてくれます。
AWS Trusted Advisor のセキュリティのセクションは定期的にチェックして頂き、AWS アカウントの健全性を評価するべきです。現時点では複数のセキュリティに関するチェックが実行されるようになっています。例えば、IAM アクセスキーがローテションされていない、セキュリティグループの設定が安全ではないなどです。Trusted Advisor は日次あるいは週次の間隔で AWS アカウントのチェックをより簡単に実施することが出来るツールです。

git-secrets

git-secrets は GitHub の AWS Labs アカウントより提供されています。git リポジトリにパスワードやその他の機微なクレデンシャルをコミットしないようにします。git-secrets はコミットそのものやコミットメッセージをスキャンし、gitの —no-ff オプションを追加することで不意に機密情報がリポジトリに追加されることを防ぎます。

まとめ

このブログ記事では、アプリケーションコードの中に長期間有効な認証情報を持たせる代わりに、一時的なアクセス認証方法を持たせることが出来る AWS プラットフォーム上のツールとサービスを紹介しました。一時的なアクセス認証情報を利用することで被害範囲が拡大するリスクを低減することが出来、ビジネスを守ることが出来ます。
また、最小権限のコンセプトについて説明し、組織で利用される様々な ID のパーミッションの運用と監査の手続きに利用出来るサービスについても説明しました。
もし、この記事に関してご質問やフィードバックがある場合には、当記事のコメント欄にコメント頂くか、AWSサポートにコンタクトしてください。

翻訳はソリューションアーキテクト髙橋悟史が担当しました。原文はこちらです。

Amazon Web Services ブログ