AWS再入門 AWS IAM (Identity and Access Management) 編
当エントリはDevelopers.IOで弊社AWSチームによる『AWS サービス別 再入門アドベントカレンダー 2015』の22日目のエントリです。昨日21日目のエントリは半瀬の『AWS Trusted Advisor』でした。
このアドベントカレンダーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。
本日22日目のテーマは『IAM (AWS Identity and Access Management)』です。
もし、IAMがなかったら1つのAWSアカウントを複数人で共有し、誰が何のリソースに、どのような操作をしたかを把握することは不可能です。IAMは、AWS マネジメントコンソールや API によって素早く低コストでセキュリティを担保することが可能です。
目次
IAMとは?
IAM(AWS Identity and Access Management) は、AWSユーザーに対して AWSのリソースへのアクセスできる範囲やアクセス方法を安全に制御するためのウェブサービスです。IAM により、どのユーザーが AWS リソースを使用できるか(認証)、また、それらのユーザーがどのリソースをどのような方法で使用できるか(認可)を制御できます。
IAMを利用するには
- AWS マネジメントコンソール
- AWS コマンドラインツール
- AWS SDK
- IAM HTTPS API
一般には AWS マネジメントコンソールの IAM の画面から利用します。
※ IAMユーザーのサインイン画面は、「IAMユーザーのサインインリンク」をご利用ください。AWSアカウントのサインイン画面と異なります。
https://AWS-account-ID-or-alias.signin.aws.amazon.com/console
IAMも他のサービスと同様に、自動化が可能です。 シェルスクリプトから利用するには AWS コマンドラインツール(AWS Command Line Interface (AWS CLI)、AWS Tools for Windows PowerShell)が提供されています。 アプリケーションに組み込むには AWS SDK(Java、Python、.NET、iOS、Android、Ruby、Node.js、PHP、C++、Go、ブラウザ など)や WebAPI(IAM HTTPS API)を利用できます。
IAMの基本
[大前提] AWSアカウントは直接利用しない!
最初にAWSを利用する時に、AWSアカウントを取得しますが、このアカウントはリソースへのフルアクセスを許可します。お客様ごとのAWS環境は、複数の利用者やプログラムなどによって利用されますので、原則的にAWSアカウントやそのシークレットアクセスキーを直接利用することはお勧めできません。なので、実際には用途や目的ごとにAWSアカウントをから、IAMユーザーやIAMロールを作成して、AWSを利用します。そうすることで、IAMユーザーやIAMロールごとのアクセス管理、承認、監査(AWS CloudTrail)が可能になります。
※ UNIXの「root」アカウントの直接利用、Windowsの「Administrator」の直接利用は望ましくないというのと同じ考えに基づきます。
IAM利用の流れ
IAMユーザーの作成を例にしますと、IAMユーザーは1つ以上のIAMグループに所属させ、IAMグループは1つ以上のIAMポリシーを設定します。UNIXやWindowsのユーザー管理と基本的に考え方は一緒です。
以降では、IAMユーザー、IAMグループ、IAMポリシーについて解説します。
IAMユーザー
IAMユーザーとは、AWSを利用するアカウントに相当します。IAMユーザーの登録はユーザー名を入力します。ユーザーの作成時にアクセスキーを作成したい場合は「ユーザーごとにアクセスキーを生成」を選んでください。
新規登録したIAMユーザーはパスワードが設定されていないのでログインできません。IAMユーザー一覧から、ユーザー名を選択するとそのユーザーの設定画面となります。デフォルトではパスワードが設定されていませんので、「認証情報」タブの「サインイン認証情報」の [パスワード管理]ボタンを押したパスワード変更画面から変更してください。
IAMグループ
IAMグループとは、IAMユーザーをまとめて管理するグループで、IAMユーザーは複数のグループに登録できます。 IAMユーザーの登録の手順1では、グループ名を入力します。
手順2では、IAMポリシーを指定します。ここでは、「AmazonS3ReadOnlyAccess」を設定します。AWS管理ポリシーやカスタム管理ポリシーがたくさん登録されていますので、目的のポリシーを「フィルター」で検索すると良いでしょう。(IAMポリシー、AWS管理ポリシー、カスタム管理ポリシーについては後述します。)
新たに作成したIAMグループをIAMグループ一覧から選択して、「ユーザー」タブの[グループにユーザーを追加]ボタンを押すと、IAMユーザー一覧が表示されますので、追加したいユーザー名を選択してください。
IAMポリシー
IAMポリシーとは、AWSリソースに対する権限を設定です。
IAMポリシーは以下の3つの方法で作成できます。
- AWS 管理ポリシーをコピー
- Policy Generator
- 独自のポリシーを作成
基本的にはJSON形式のアクセスポリシー言語でアクセス条件を記述しますが、AWS 管理ポリシーからカスタマイズしたり、Policy Generatorによる質問形式で条件を入力することでIAMポリシーの生成が可能です。
Policy Generatorでは、条件を入力して[ステートメントを追加]ボタンを押すと、下に次々と追加されます。
次の画面では生成されたポリシーのJSONが参照・編集できます。[ポリシーの検証]ボタンを押すことで、作成前に構文の検証ができます。ポリシーの検証は、DryRunではないので存在しないリソースを指定してもエラーとなりません。
作成したIAMポリシーは、アカウントのユーザー、グループ、またはIAMロールに設定(アタッチ)できます。(IAMロールについては後述します。)
補足:AWS管理ポリシー、カスタム管理ポリシー、インラインポリシー
今年の2015年2月以前のポリシーはインラインポリシーのみでした。今後は変更管理の一元化できるAWS管理ポリシー、カスタム管理ポリシーを活用することをおすすめします。
IAMロール
IAMロールとは、IAMユーザーやIAMグループではなく、AWSサービスやアプリケーション等、エンティティに対してにAWS の操作権限を付与するための仕組みです。オンプレの世界では存在しない概念なのでいまいちピンとこないかもしれませんので、具体例を上げてご説明します。
IAMロールには、以下の3種類あります。
- AWS サービスロール
- クロスアカウントアクセスのロール
- ID プロバイダアクセス用のロール
AWS サービスロール
AWS サービスロールとは、AWSサービスに対してにAWS の操作権限を付与するための仕組みです。 IAMロールをEC2インスタンスに付与すると、そのEC2インスタンス上で実行するAWSCLIやAWS SDKはクレデンシャルなしで利用できます。そんなことができて何が嬉しいかというと、EC2上にクレデンシャルを置かなくても良いのでクレデンシャルの漏洩リスクを回避できることや、EC2のAMIを別の環境へ移行した時に変更無しで再利用できることです。
※ EC2のIAMロールはインスタンスに後で付けられませんのでご注意下さい!
クロスアカウントアクセスのロール
あるIAMアカウントに対して別のアカウントのIAMロールを紐付ける機能です。例えば、本番環境に触れるロールを事前に作っておき、必要な時にそのロールにスイッチすることで、IAMユーザ一を作らずに他のアカウントのIAMユーザーが一時的に本番環境に触れるようにすることができます。
クロスアカウントアクセスの設定は【新機能】IAMユーザーをManagement Consoleからクロスアカウントで色々なRoleにスイッチする事ができるようになりました。 を参考にしてください。
ID プロバイダアクセス用のロール
外部の認証機構である 外部 ID プロバイダーサービス(IdP)との連携を設定します。以下の具体例については、後述の AWS Security Token Service(STS) で紹介します。
- ウェブ ID プロバイダにアクセスを付与
- SAML プロバイダへのウェブシングルサインオン(WebSSO)アクセスを付与
- SAML プロバイダに API アクセスを付与
IAMの活用
IAMアカウントの運用
発行したIAMアカウントは、以下のポリシーに基づいて、更新を促す様に設定が可能です。
- パスワードポリシーの利用
- パスワードローテーション
- アクセスキーのローテーション
多要素認証(MFA)
ユーザー・パスワード漏洩によるなりすましの防止には多要素認証(MFA)の導入が効果的です。専用のハードウェアとソフトウェアがあります。今回は導入が容易な2つのモバイルアプリを紹介します。
AWS Multi-Factor Authenticationでvirtual MFA devicesとしてGoogle Authenticatorを利用
IAM認証情報レポート(Credential Report)
Credential Reportメニューから認証情報レポートは、カンマ区切り値(CSV)ファイルとしてダウン ロード可能です。認証情報ライフサ イクルの要件の結果を監査にご利用ください。
ユーザーのアクティビティの記録
AWS CloudTrailはAWSアカウントで利用された全てのAPI Callを記録するサービスです。全リージョンでの有効化を推奨します。IAMのアクテビティの監査にご利用ください。
AWS Security Token Service(STS)
AWS Security Token Service(STS)とは、一時的に利用するトークンを発行するサービスで、動的にIAMユーザーを作成し、ポリシーを適用できます。EC2インスタンスに付与したIAMロールから一時クレデンシャルを取得することにも利用されています。
今回のIAM再入門では、あえてSTSを意識させずにIAMの機能や活用について解説してきましたが、ID連携の利用について理解するためには必須の知識となります。
認証情報取得のAPIは以下の5種類です。
IAMロールによるクロスアカウントアクセス
IAMロールの解説したクロスアカウントアクセスは、実は内部ではSTSを利用して実現した機能です。
API FederationによるAWSリソースへのアクセス
Windows Active Directory認証したユーザーのAWSアクセス権を紐付けはFederationProxyが行い、FederationProxyのGetFederationTokenリクエストによって、テンポラリセキュリティクレデンシャルを取得することで実現します。
Console Federation 管理コンソールへのシングルサインオン
Windows Active Directory認証したユーザーのAWSアクセス権を紐付けはFederationProxyが行い、ListRoleリクエストで権限の一覧を取得、AssumeRoleリクエストでテンポラリセキュリティクレデンシャルを取得してシングルサインオンを実現します。
次にご紹介する方法ではより簡単に管理コンソールへのシングルサインオンが可能です。
SAML プロバイダへのウェブシングルサインオン(WebSSO)
IAMは SAML2.0をサポートしており、新しいAssumeRoleWithSAML APIによりAPIフェデレーションが可能になりました。SAMLを利用してADFSといった既存のID管理ソフトウェアによるAWSリソースへのアクセスできますので、マネジメントコンソールのシングルサインオンにも利用できます。FederationProxyサーバーのような紐付けするサーバー不要な点が優れています。
Web Identity Federation によるAWSリソースアクセス
Google、Facebook、Amazon(Login with Amazon)、Amazon、Cognito及びOIDC準拠のID プロバイダの認証とAWSのアクセス権を紐付けて連携させるユースケースです。モバイルアプリはウェブ ID プロバイダに対してユーザー認証してIDトークンを取得します。このIDトークン使ってSTSに対して一時的な認証情報取得をリクエストして一時的な認証情報を取得します。
ベストプラクティス
「IAMとは?」〜「IAMの活用」まで実践していただければベストプラクティスは網羅しているはずです。現在のIAMのチェックリストとしてご活用ください。
合わせて読みたい
最後に
「AWS Security Token Service(STS)」は必要に応じて、「IAMとは?」〜「IAMの活用」まで読んでいただければ、十分ご活用いただけると思います。
以上、 『AWS サービス別 再入門アドベントカレンダー 2015』の22日目のエントリ『AWS IAM (Identity and Access Management) 』でした。
明日(12/23)はせーのの「SWF」の予定です!どうぞお楽しみに♪