本講座では、コーポレートサイトのシステムを題材に、セキュリティを強化する方法を解説します。

 AWSには「権限の管理」「検出制御」「データ保護」「インフラストラクチャーの保護」というセキュリティの4分野をサポートするサービス・機能が用意されています。第1回では権限の管理と検出制御を解説し、インフラストラクチャーの保護についても触れます。データ保護(暗号化)は第2回で取り上げます。

権限の管理に使用するIAM

 仮想マシンのAmazon EC2、ロードバランサーのALB、オブジェクトストレージのAmazon S3といったAWSのサービスを利用して、コーポレートサイトのシステムを構築してきました。これらAWSのリソースに対するアクセス権限についてどう考えたらよいでしょうか。

 セキュリティのベストプラクティスは、与えるアクセス権限も、ユーザーの範囲も、必要最小限に絞り込むことです。例えば、VPC(Virtual Private Cloud)の作成、EC2インスタンスやRDSインスタンスの起動・停止といった操作はインフラ管理チームのみが行えるようにし、アプリケーション開発チームが不用意にインフラの構成を変更できないようにするといった具合です。

 AWSリソースへのアクセス権限の管理に利用するサービスが「IAM(Identity and Access Management)」です。IAMによって、AWSリソースにアクセスできるユーザーであることを確認(認証)したうえで、起動、設定、管理、終了といった操作を許可(認可)します。例えば、限られたインフラ管理担当者のみに特定のEC2インスタンスの起動・停止を許可したり、あるEC2インスタンスに特定のS3バケットへの読み書きを許可したりできます。

 AWSリソースへのアクセス方法にはAWSマネジメントコンソールの操作とAPIコールがあり、異なるセキュリティ認証情報を使用します。マネジメントコンソールでは、ユーザー名とパスワードを使用してサインインします。APIコールではアクセスキーを使用します。

 IAMにはアクセス権限をリスト化した「IAMポリシー」と、それを割り当てるユーザーの範囲である「IAMユーザー」「IAMグループ」「IAMロール」という概念が存在します。IAMユーザー、IAMグループ、IAMロールは総称して「IAMエンティティ」と呼びます。一つずつ解説します。

 IAMポリシーは、1個あるいは複数個のアクセス権限をまとめたものです。JSON(JavaScript Object Notation)形式で保存されるので、GitHubのようなバージョン管理システムによって管理できます。

 IAMポリシーでは、許可しない限りは全ての操作が拒否されます。これを「暗示的な拒否」と呼びます。

 操作を許可するには、IAMポリシーに書く必要があります。これが「明示的な許可」です。明示的な許可は、暗示的な拒否より優先されます。

 二つのアクセス権限(ステートメント)を表した、IAMポリシーの具体例を図1に挙げます。

図1●IAM ポリシーの許可・拒否ステートメント
許可ステートメントと明示的な拒否ステートメントを併用することで、他のIAMポリシーがアタッチされても、このIAMポリシーで許可したリソースにしかアクセスできないことを保証する
[画像のクリックで拡大表示]

 前半は明示的な許可ステートメントで、mytableというDynamoDBテーブル、mybucketというS3バケットおよびそこに保存された全てのオブジェクトに対するあらゆるアクションの権限を付与します。

 後半は明示的な拒否ステートメント。mytableというDynamoDBテーブル、mybucketというS3バケットおよびそこに保存された全てのオブジェクト以外へのアクションを拒否します。前半の補集合についての拒否なので、矛盾しません。デフォルトは暗示的な拒否のため、後半のステートメントがなくても同じ結果になります。

 後半のステートメントは冗長なように見えますが、明示的な拒否も定義することには意味があります。明示的な許可と明示的な拒否が存在する場合、拒否が優先されます。そのため図6-1のIAMポリシーをアタッチすれば、別のどんなIAMポリシーを追加しても、mytableというDynamoDBテーブル、mybucketというS3バケットおよびそこに保存された全てのオブジェクト以外へのアクションを拒否します。

IAMユーザーの集合がIAMグループ

 続いて、3種類あるIAMエンティティを説明します。

 まずIAMユーザーは、AWSリソースの操作用IDです。主に、AWSマネジメントコンソールへのサインインと、AWSリソースへのAPIコールを行う際に使用します。1個のAWSアカウントで、5000個までのIAMユーザーを作成できます。

 IAMユーザーは、アクセス権限が関連付けられた単なるIDであり、アプリケーション用に作成することもできます。その場合、アプリケーションからAWSリソースのAPIをコールする際に使います。

 アプリケーション用のIAMユーザーに対してアクセスキーを作成できます。アプリケーションはアクセスキーを使用して認証を受けます。

 IAMユーザーの集合がIAMグループです。グループ単位でアクセス権限を管理できます。例えば開発者をグループ化したDevelopersというIAMグループを作成し、開発者に共通して必要な権限を割り当てます。

 こうしておけば、開発者がプロジェクトに新たに加わったとき、その開発者のIAMユーザーをDevelopersに追加するだけで、開発者に必要な権限を割り当てることができます。同様に、開発者がプロジェクトから外れたときは、そのIAMユーザーをDevelopersから削除すれば済みます。

 一つのIAMユーザーを、複数のIAMグループに重複して所属させられます。ただしIAMグループを入れ子形式にする機能はありません。つまり、あるIAMグループに他のIAMグループが属する、という構成にはできません。

 AWSアカウント内の全てのIAMユーザーが属するIAMグループが必要になることがあります。これはデフォルトでは存在しないので、作成する必要があります。手間が掛かりますが、IAMユーザーを一つずつ割り当てます。

一時的なアクセス権限を付与するIAMロール

 IAMロールを使うと、通常はアクセス権限を持たない人やアプリケーションなどに対して、アクセス権限を安全に付与できます。例えばAWSアカウントのユーザーに、別のAWSアカウントのリソースに対するアクセス権限を付与するといった具合です。S3バケットやDynamoDBのテーブルの読み書きを行う必要がある、EC2インスタンス上のアプリケーションコードやLambdaファンクションのようなAWSサービスに、アクセス権限を付与することも可能です。

 Active Directoryのような社内ディレクトリーサービスでAWS以外のIDを持っているユーザーや、FacebookやAmazon.comといった外部IDプロバイダー(IdP)によって連携されたユーザーに対して、AWSリソースへのアクセス権限を付与することも可能です。IdPとの連携を「Web IDフェデレーション」と呼びます。

 ここで、人やアプリケーションにIAMロールを割り当てることを「(人やアプリケーションが)IAMロールを引き受ける」と言います。具体的には、AWS Security Token Service(STS)のAssumeRole APIをコールし、IAMロールに関連付けられたアクセス権限を持つ一時的セキュリティ認証情報を付与します。

 IAMロールは、IAMユーザーとどう違うのでしょうか。AWSリソースに対するアクセス権限ポリシーが関連付けられたAWS IDであるという点で、IAMロールはIAMユーザーと似ています。しかしIAMユーザーは特定の人やアプリケーションに一意に関連付けられますが、IAMロールは複数の人やアプリケーションが引き受けられます。

 IAMロールにはパスワードやアクセスキーといった長期セキュリティ認証情報を関連付けられないという点も、IAMユーザーと異なります。代わりに、人やアプリケーションがIAMロールを引き受けた場合、一時的セキュリティ認証情報(有効期限を持ったアクセスキー)が動的に作成・提供されます。IAMロールを引き受けた人やアプリケーションは、一時的セキュリティ認証情報を使って、AWSリソースにアクセスします。

 誰でもIAMロールを引き受けられるようでは、セキュリティ上の問題です。そこでIAMロールを作成する際に、そのIAMロールを引き受けられる人やアプリケーションを指定します。これを「プリンシパル」と呼びます。

 プリンシパルとして、自社・他社のAWSアカウントのIAMユーザー、IAMグループ、IAMロール、EC2などAWSのサービス、SAMLプロバイダー、Login with Amazon、Facebook、GoogleといったIdPを指定できます。

 IAMロールの典型的なユースケースは、EC2インスタンス上のアプリケーションにAWSリソースへのアクセス権限を付与することです。アプリケーションのIAMユーザーを作成し、アクセスキーを発行してアプリケーションで使用することでAWSサービスへのアクセス権限を付与することもできます。しかしIAMロールを使用すれば、アクセスキー(IAMユーザーの認証情報)をアプリケーションに持たせる必要がなくなり、その漏洩リスクを低減できます。

 アプリケーション開発チームのリーダーに、インフラの構成を変更する権限を関連付けたIAMロールを引き受けさせて、一時的に権限を付与するといったこともできます。

 組織外の人に、自組織のAWSリソースへアクセスさせる場合にも、IAMロールを使用します。例えば、自社のAWSリソースの管理をITサービスのベンダーに外注している場合、IAMロールを使用することでITサービスのベンダーにAWSリソースへのアクセス権限を付与できます。ITサービスのベンダー用のIAMユーザーを作成して、AWS認証情報を共有する必要はありません。

 ルートアカウントという、Linux環境におけるrootユーザーに相当するユーザーについての注意点を挙げます。

 AWSのアカウントを作成すると、メールアドレスとパスワードでAWSマネジメントコンソールにサインインし、AWSのリソースを操作できます。メールアドレスとパスワードで認証するこのユーザーが、ルートアカウントです。

 ルートアカウントでは、全てのAWSリソースにアクセスできます。リソースへのアクセス許可を制御できないので、ルートアカウントを使うことは推奨されません。代わりにIAMユーザーを作成し、必要な権限をIAMポリシーによって付与します。

CloudTrailとAWS Config

 IAMを使用して適切なアクセス許可を設定したとしてもまだ安心できません。例えばインフラ担当者が間違えてインスタンスを削除したり、アプリケーションのバグによってDynamoDBに意図しない書き込みが行われたりといったことが考えられます。こうしたリスクを低減させるのに役立つのが、「AWS CloudTrail」と「AWS Config」です。順に紹介します。

 CloudTrailは、IAMエンティティやAWSのサービスによるAPIコールおよび関連イベントのログを記録するサービスです。イベントログには、AWSマネジメントコンソール、AWS CLI(Command Line Interface)、AWS SDK、APIで実行したアクションも含まれます。ログはAmazon S3にファイルとして保存されます。

 ログの中身は、アクションを実行した人やアプリケーション、対象リソース、イベントの発生日時などです。CloudTrailはそれらのデータを取得、表示、検索、ダウンロード、アーカイブ、分析、応答する機能を備えます。

 AWS Configは、AWSアカウントで利用しているAWSリソースの目録を作成し、構成(設定)の変更管理を行うサービスです。特定時点でのリソースの設定情報を参照したり、設定変更を通知したり、設定内容がルールに合致しているかどうかを判定したりします。AWSが用意した標準のルールだけでなく、カスタマイズしたルールも使えます。設定変更の通知は、Amazon SNS(Simple Notification Service)と連携して行われます。

 AWS ConfigとCloudTrailを組み合わせると、特定の設定変更について、関連するイベントを素早く見つけ出せます。例えばEC2インスタンスをSecurity Groupから外すようなルール違反の設定変更が行われると、AWS ConfigがAmazon SNSを通じて管理者に通知。管理者はCloudTrailの画面で、どのIAMユーザーが設定変更したのかを特定できます。

 これは、検出制御だけでなくインフラストラクチャーの保護にも該当します。

コーポレートサイトに適用する

 コーポレートサイトのシステムに権限管理と検出制御のサービスを組み込んで、セキュリティを強化しましょう(図2)。

図2●権限管理と検出制御を行いセキュリティを高めた構成
[画像のクリックで拡大表示]

 まずIAMユーザー、IAMグループ、IAMロールを作成していきます。要員一人ひとりのIAMユーザーを作成したうえで、IAMグループを検討します。ここでは「管理者」「アプリケーション開発者」「インフラ開発者」というIAMグループを作成します。これら三つのIAMグループごとに、最小限のアクセス権限を記述したIAMポリシーをアタッチします。

 続いて、Web・APサーバー用と、動画アップロード機能で使うLambdaファンクション用のIAMロールを作成します。Web・APサーバー用のIAMロールには、DynamoDBへの読み書き権限を記述したIAMポリシーをアタッチします。

 動画アップロード機能のLambdaファンクションについては、クライアントからの動画受け取り用のLambdaファンクションと、動画のエンコードを行うLambdaファンクション用とで、別々のIAMロールを作成します。前者にはS3バケット、DynamoDB、SNSへのアクセス権限を、後者にはS3バケット、DynamoDBへのアクセス権限を記述したIAMポリシーをそれぞれアタッチします。さらに、検出制御を行うためAWS CloudTrailとAWS Configを有効にします。

 今回の内容の理解度を確かめる設問を以下に載せました。ぜひ挑戦してください。

■設問1

 Amazon EC2で動作させるアプリケーションからAmazon S3バケットのデータをダウンロードできるようにします。最も安全な設定は次のどれですか(一つを選択)。

  1. S3バケットへのアクセス権限を持つIAMユーザーを作成する。IAMユーザーの認証情報をEC2インスタンスにcredentialsファイルとして保存し、アプリケーションから参照する
  2. S3バケットへのアクセス権限を持つIAMユーザーを作成する。アプリケーションにIAMユーザーの認証情報を埋め込んでおく
  3. S3バケットへのアクセス権限を持つIAMロールを作成する。アプリケーションにIAMロールの認証情報を埋め込んでおく
  4. S3バケットへのアクセス権限を持つIAMロールを作成する。アプリケーションを稼働させるEC2インスタンスにこのIAMロールを割り当てる

■設問2

 Amazon EC2インスタンスを作成する際、社内ルールに沿ったインスタンスタイプやタグを使用するように統制します。ルール違反のインスタンスが作成されたとき運用管理者に通知するうえで、最も手軽に導入できるのは次のどのサービスですか(一つを選択)。

  1. Amazon CloudWatch Logs
  2. AWS CloudTrail
  3. AWS Config
  4. AWS Trusted Advisor

■設問3

 不特定多数の利用者が使うモバイルアプリケーションをEC2インスタンスでホストします。利用者固有のステータス情報をAmazon DynamoDBへ保存し参照するために、利用者別に権限を設定する最も適切な方法はどれですか(一つを選択)。

  1. Web IDフェデレーションを使用して利用者を識別し、AWS STS(Security Token Service)から一時的な認証情報を取得する
  2. 利用者の初回アクセス時にメールアドレスをキーとしたアカウントを登録し、対応するIAMユーザーを作成して認証情報を管理する
  3. DynamoDBの読み込みと書き込み権限を付与したIAMロールをEC2インスタンスに割り当てる
  4. モバイル端末固有のハードウエア情報を基に利用者を識別し、DynamoDBの特定テーブルにアクセスするための一時的な認証情報を渡す

 解答・解説は以下を参照。

□設問1の答:D

 IAMユーザーを作成すると、AWSのリソースへアクセスするための2種類の認証情報が利用可能になります。一つはユーザー名とパスワードで、Webブラウザーからマネジメントコンソールへのアクセスに使います。もう一つは、アクセスキーIDとシークレットアクセスキー。API経由でのユーザーの認証に使用します。

 悪意あるユーザーにこれらの認証情報を利用されないため、安全に保管したうえで定期的に更新するといったメンテナンスが必要です。ファイルやコード内にこれらの認証情報を保管すると、漏洩リスクが高まります。選択肢A、Bはどちらも実装可能ですが、漏洩リスクがあるため推奨されておらず、誤りです。

 IAMロールには、権限を定義したIAMポリシーを割り当て、IAMユーザーやグループにアタッチします。つまりIAMロールは固有の認証情報を持たないので、Cも誤りです。

 IAMロールはEC2インスタンスやLambdaファンクションなどAWSのリソースにもアタッチできます。例えばEC2インスタンスにIAMロールを割り当てると、権限が必要なAPIリクエストの実行時には「インスタンスメタデータ」という仕組みを介して一時的な認証情報を安全に渡します。正解はDです。

□設問2の答:C

 ルール違反を判定する独自スクリプトを作成しておき、EC2インスタンスの起動時に実行し、違反があればログに記録。そのログをCloudWatch Logsで分析し、ルール違反のEC2インスタンスを見つけ出せる可能性があります。しかし実現できても、スクリプト開発やルール管理は容易ではありません。Aは誤りです。

 CloudTrailは、AWSの各種サービスに対して実行されたAPIリクエストの記録を残すサービスです。CloudTrailは、新しいログファイルをAmazon S3バケットに発行するとき通知する機能を備えていますが、ルール違反であるかどうかを判定するような機能はありません。Bも間違いです。

 Trusted Advisorは、コスト、パフォーマンス、耐障害性、サービスの制限、セキュリティという観点で、ユーザーがAWSに構築したインフラが適切かどうかを検証するサービスです。最新の変更をダッシュボードに表示する機能はありますが、特定の変更内容についての通知は行われません。Dも誤りです。

 AWS Configを使用すると、「EC2インスタンスにはElastic IPアドレスをアタッチする」といったマネージドルールおよびカスタムルールに基づいて、作成・変更されたAWSのリソースを評価します。正解はCです。

□設問3の答:A

 IAMユーザーの作成上限は5000で、不特定多数の利用者ごとに作成するには不向きです。Bは誤りです。

 クライアントの識別方法など、設問の要件にある利用者別の権限の設定が考慮されていないことから、Cは不適切です。

 スマートフォンの買い換え、家族や他人による使用などがあることから、端末固有のハードウエア情報を利用者の識別に用いるべきではありません。Dも誤りです。

 Amazon.comやFacebookなど外部のIDプロバイダーで認証するWeb IDフェデレーションによって利用者を識別し、AWS STS(Security Token Service)で一時的な認証情報を付与できます。このときIDと同名のDynamoDBテーブルに限定したアクセス権限を割り当てることで、利用者は固有の情報のみにアクセスできるようになります。正解はAです。

堀内 康弘(ほりうち・やすひろ)
モビンギ 取締役、M&Aナビ 技術顧問
ブイキューブ、gumiを経て、2012年3月にアマゾン データ サービス ジャパン(現・アマゾン ウェブ サービス ジャパン)入社。テクニカルエバンジェリストとして活躍。2014年10月に退職し、2015年1月モビンギ 取締役に就任。2019年2月からM&Aナビ 技術顧問を兼務。トレノケートでAWS公式トレーニングの講師を務める。
三浦 美緒(みうら みお)
トレノケート ラーニングサービス本部 ラーニングサービス第1部 技術教育エンジニア
外資系ITベンダーでオープン系エンタープライズシステムの運用監視環境の設計、構築に従事した後、2002年より現職。Linux、Apache、BINDなどのトレーニング企画、提案、実施を担当。近年はAWS認定インストラクターとして研鑽中。
出典:『Amazon Web Services エンタープライズ基盤設計の基本』(日経BP社)の第6章を改編
記事は執筆時の情報に基づいており、現在では異なる場合があります。