AWS IAM とは何か

フェイス・ソリューション・テクノロジーズ株式会社 IS 本部 OS ユニットの Saki＠猫好きです。AWS 活用していますか？

いくら AWS 認定資格 6 冠を達成していても、基本は大事。今日は、IAM について学習しなおしてみようと思います。いえ、どちらかというと、AWS 初心者の OS ユニットのメンバーの「お勉強のお時間」です！

はじめに

AWS IAM とは

IAM（Identity and Access Management）とは、AWS リソースへのアクセスを安全に管理するための AWS サービスの一つです。

IAM により、誰を認証（サインイン：ユーザー管理）し、誰にリソースの使用を承認する（アクセス許可：権限管理）かを制御します。

AWS アカウントを作成する場合は、このアカウントのすべての AWS のサービスとリソースに対して完全なアクセス権を持つ 1 つのサインインアイデンティティから始めます。この ID は AWS アカウントルートユーザーと呼ばれ、アカウントの作成に使用した E メールアドレスとパスワードでサインインすることによってアクセスできます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。

アカウントを作成したときに同時に作成されるユーザーは、なんでもできるルートユーザーなので、日常的なタスクには使わないようにしましょう、とのことです。日常的なタスクを行うためのユーザーを作成して、作成したユーザーがどの AWS サービスを操作できるようにするか管理するために使用するのが、AWS IAM です。

お勉強のお時間とは

Saki＠猫好きがメンバーに対して突然始める、文字通りの「お勉強」のお時間。もちろん、勤務時間中にやります。メンバーからの質問に対して、Saki＠猫好きが親切丁寧に説明します。Saki＠猫好きがちょっと知識に不安なときは、きちんと学習をしなおしてから、メンバーに対して「お勉強のお時間」を行います。

AWS だけでなく、日常業務のことでも、それ以外のことでも、事務所内は気軽に会話ができる環境です。

IAM の機能

AWS 公式で紹介されている順番に、噛み砕いて見てみたいと思います。

AWS アカウントへの共有アクセス

パスワードやアクセスキーを共有しなくても、お客様の AWS アカウントのリソースを管理および使用するためのアクセス許可を他の人に付与できます。

これは、ロールを使用することで設定できます。一例として、ロールの作成で選択することができる「AWS アカウント」ならば、他の「AWS アカウント」から、自分の AWS アカウントの AWS サービスへアクセスすることができるようになります（添付画像）。

AWS 公式の説明によると、アクセス許可を付与している、と書かれているところに注目。自分の AWS アカウントの EC2 サービスへアクセスして良いよ、と言っているだけで、EC2 に対して何をして良いかについては言っていない。

詳細なアクセス権限

リソースごとに、ユーザーごとに、さまざまなアクセス権限を付与できます。たとえば、一部のユーザーは、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB、Amazon Redshift、他の AWS のサービスへの完全なアクセスを許可する場合があります。他のユーザーには、一部の S3 バケットへの読み取り専用アクセス、一部の EC2 インスタンスのみへの管理アクセス、または請求情報のみへのアクセスを許可できます。

これは、ポリシーを使用することで設定できます。さきほどのロールでアクセスを許可された AWS サービスで、「何をしていいか」を指定します。たとえば、ポリシーの作成で EC2 サービスを選択すると、アクセスレベルをどのように指定するか選択して作成することができます（添付画像）。

これは、AWS 公式の説明にある「ユーザーごと」にアクセス権限を付与するという話。「リソースごと」にもアクセス権限を付与することができます。最初はイメージがつきにくいと思いますが、とっても重要。

ユーザーごと	ユーザー A さんは EC2 インスタンスを作成できる
リソースごと	EC2 インスタンスは S3 にアクセスできる

Amazon EC2 で動作するアプリケーションから AWS リソースへの安全なアクセス

IAM の機能を使用して、EC2 インスタンスで実行されているアプリケーションの認証情報を安全に提供できます。これらの認証情報は、他の AWS リソースにアクセスするためにアプリケーションのアクセス許可を提供します。例として、S3 バケットや DynamoDB テーブルなどがあります。

これは、EC2 インスタンスへロールをアタッチすることで達成できます。

普段、ローカル環境（ご自身の PC）から AWS CLI を利用することはありますか？ないですか。それは残念。AWS CLI は、ざっくり言うと、コマンドで AWS サービスをいろいろ出来ちゃう凄いヤツです。是非、使ってみてください。

さて、AWS CLI を使う場合、aws configure というコマンドで、初期設定を行います。その際、アクセスキーとシークレットアクセスキーを設定する必要があります。しかし、PC が盗まれてしまったり、ショルダーハッキングされてしまったりして、アクセスキーとシークレットアクセスキーが漏洩してしまったら、攻撃者に AWS サービスを好き勝手利用されてしまう恐れがあります。

EC2 インスタンスでも、同様なことが言えます。

たとえば、EC2 インスタンスでデータを作成して、そのデータを S3 へ保存するというパブリックなアプリケーションがあるとします。ネットでは、「ユーザーを新たに作成して EC2 インスタンスに AWS CLI でそのユーザーのアクセスキーとシークレットアクセスキーを設定する」という手順が頻繁に紹介されていませんか？これは悪手。アクセスキーとシークレットアクセスキーをパブリックな場所に置いておくということは、あなたの家の鍵を玄関前の鉢植えの下に隠しておく、みたいなもの。いつ、どんな脆弱性が見つかって情報を盗まれてしまうかわかりません。

そこで、EC2 インスタンスにロールをアタッチする方法です（添付画像）。

ちゃんと「セキュリティ」の項目に「IAM ロールの変更」があります。ロールをアタッチする、というのはセキュリティ的にも重要な意味を持っていることがわかります。

S3 にファイルをアップロードすることができるポリシーを設定したロールを EC2 インスタンスにアタッチする。

これで、アクセスキーとシークレットアクセスキーを意識しなくとも、EC2 インスタンスから S3 にファイルをアップロードすることができるようになります。万が一、脆弱性が見つかって EC2 インスタンスの情報を盗まれたとしても、ロールをデタッチすれば、S3 へアクセスすることはできません。

AWS を利用するうえで、最も重要なファクターの一つであると思います。是非、利用してみてください。

多要素認証（MFA）

アカウントおよび個々のユーザーに 2 エレメント認証を追加することで、セキュリティを強化できます。MFA を使用すると、ユーザーはお客様のアカウントで使用しているパスワードまたはアクセスキーの入力だけでなく、特別に設定されたデバイスからのコードの入力も必要になります。既に他のサービスで FIDO セキュリティキーを使用している場合、それには AWS がサポートする設定があります。詳細については、FIDO セキュリティキーを使用するためのサポートされる設定を参照してください。

これは、言わずと知れた多要素認証。サインインする際に、パスワード以外にもう一つ、何かの認証方法を追加して、安全性を高めるものです。AWS がサポートしている必要があります。ほとんどのものはサービスされていますが、TouchID や、FaceID、Windows Hello といった、プラットフォームオーセンケーターはサポートされていません。

IAM の各ユーザーで、MFA の設定を管理することができます（添付画像）。

Saki＠猫好きは、WinAuth を利用することが多いです。

ID フェデレーション

他の場所 (社内ネットワーク、インターネット ID プロバイダーなど) でパスワードをすでに持つユーザーに、お客様の AWS アカウントへの一時的なアクセスを許可できます。

これは、SSO のお話。IAM のコンソール画面ですと、ID プロバイダとなります（添付画像）。

現在は、AWS SSO の後継のサービスとなる AWS IAM Identity Center で管理することをオススメします。

保障のための ID 情報

AWS CloudTrail を使用している場合は、お客様のアカウントのリソースをリクエストしたユーザーに関する情報がログレコードに保存されます。その情報は IAM ID に基づきます。

AWS アカウントの運用とリスクの監査、ガバナンス、コンプライアンスを行えるように支援する AWS のサービス、AWS CloudTrail には、ユーザー、ロール、AWS のサービスによって実行されたアクションがすべて記録されます。

リソースをリクエストしたユーザーに関する情報は、IAM ID と紐づいているから誰が何をしたか、すぐにわかっちゃうよ、といった感じ。ここからはちょっと説明が難しい。

基本的には、ARN（Amazon Resource Name）が利用できる。けれど、A 部長が退職して、ユーザーを削除した後、同名の A さんが入社して、ユーザーを作成した。この場合、IAM ARN はどちらも同じになってしまう。ただし、一意の IAM ID もあるから、A 部長がアクセスできていた情報へ、A さんがアクセスできるようにしてしまう可能性が低くなる。

PCI DSS コンプライアンス

IAM は、マーチャントまたはサービスプロバイダーによるクレジットカードデータの処理、ストレージ、および伝送をサポートしており、Payment Card Industry (PCI) Data Security Standard (DSS) に準拠していることが確認されています。PCI DSS の詳細 (AWS PCI Compliance Package のコピーをリクエストする方法など) については、「PCI DSS レベル 1」を参照してください。

うん、これは、AWS は PCI DSS の認証を受けている、と覚えよう。

多くの AWS サービスとの統合

IAM と連携する AWS サービスのリストについては、「IAM と連携する AWS のサービス」を参照してください。

サービスに対するアクション、リソースレベルのアクセス許可、リソースベースのポリシー、タグに基づく承認が、多くの AWS サービスと統合しています。主要サービスについては、統合されているかされていないか、上位の AWS 認定資格試験で問われることがあるので、自然と覚えています。まぁ、主要サービスかどうかなんて、業務領域によって異なるので、「一般的に主要サービスと思われるサービスについては、」と読み替えてください。

結果整合性

IAM は、他の多くの AWS サービスと同様に、最終的に一貫性があります。IAM は、世界中の Amazon のデータセンター内の複数のサーバーにデータを複製することにより、高可用性を実現します。何らかのデータの変更リクエストが成功すると、変更はコミットされ、安全な場所に保管されます。ただし、変更は IAM 全体で複製される必要があり、これには多少時間がかかることがあります。このような変更には、ユーザー、グループ、ロール、またはポリシーの作成や更新が含まれます。アプリケーションの重要で高可用性のコードパスには、このような IAM の変更を含めないことをお勧めします。代わりに、実行頻度が低い別の初期化またはセットアップルーチンに IAM の変更を加えます。また、本番稼働ワークフローが依存する前に、変更が伝達済みであることを確認します。詳細については、「行った変更がすぐに表示されないことがある」を参照してください。

IAM は、最終的な一貫性を持っているのであって、強い結果一貫性を持っているわけではない。

EC2 インスタンスで稼働しているアプリケーションに改修を加えて S3 にファイルをアップロードできるようにした。EC2 インスタンスにアタッチしたロールのポリシーに s3:PutObject を追加して、アプリケーションを公開したが、S3 にファイルをアップロードできないといった苦情が殺到した。

というようなことが起こり得ます、ということです。少し時間をおくと、苦情はなくなった、と続くのでしょうけれど。

使用料無料

AWS Identity and Access Management (IAM) および AWS Security Token Service (AWS STS) は追加料金なしで提供される AWS アカウントの機能です。IAM ユーザーまたは AWS STS の一時的なセキュリティクレデンシャルを使用して他の AWS のサービスにアクセスした場合にのみ課金されます。他の AWS 製品の料金設定については、Amazon Web Services 料金設定ページを参照してください。

IAM と AWS STS はお金いらないから、きちんと管理してね。責任共有モデルにおける、ユーザー側が負う責任だからね。

IAM へのアクセス

IAM を利用するには、次の方法があるよ！

AWS Management Console

コンソールは IAM および AWS リソースを管理するためのブラウザーベースのインターフェイスです。コンソールから IAM にアクセスする方法の詳細については、「IAM ユーザーまたはルートユーザーとしての AWS Management Console へのサインイン」を参照してください。コンソールの使用に関するチュートリアルについては、「最初の IAM 管理者のユーザーおよびユーザーグループの作成」を参照してください。

たくさん添付した、一般ユーザーの方には見慣れた画面かもしれない。と思ったけれど、会社で利用されている方は、IAM へのアクセスは制限されていることが多いのかなぁ。弊社でも、必要以上には IAM を触れないようにしてあるし。

AWS コマンドラインツール

AWS コマンドラインツールを使用して、システムのコマンドラインでコマンドを発行することで、 IAM および AWS タスクを実行できます。コマンドラインを使用すると、コンソールよりも高速で便利になります。コマンドラインツールは、AWS のタスクを実行するスクリプトを作成する場合にも便利です。
AWS には、AWS Command Line Interface (AWS CLI) と AWS Tools for Windows PowerShell という 2 セットのコマンドラインツールが用意されています。AWS CLI のインストールおよび使用の方法については、「AWS Command Line Interface ユーザーガイド」を参照してください。Tools for Windows PowerShell のインストールおよび使用の方法については、AWS Tools for Windows PowerShellユーザーガイドを参照してください。

もちろん、AWS CLI にしても、Tools for Windows PowerShell にしても、利用するユーザーに利用可能となるポリシーがアタッチされていないといけないのだけれど。コマンドは覚えておく必要はない、都度、AWS の公式ページで調べよう！といつも思っている。

AWS SDK

AWS には、さまざまなプログラミング言語およびプラットフォーム (Java、Python、Ruby、.NET、iOS、Android など) のライブラリとサンプルコードで構成された SDK (ソフトウェア開発キット) が用意されています。SDK は、IAM や AWS へのプログラムによるアクセス権限を作成する際に役立ちます。例えば、SDK は要求への暗号を使用した署名、エラーの管理、要求の自動的な再試行などのタスクを処理します。AWS SDK のダウンロードやインストールなどの詳細については、「アマゾンウェブサービスのツール」ページを参照してください。

Saki＠猫好きがよく使っているのは、boto3 です。ここでも言います。コマンドは覚えておく必要はない、都度、AWS の公式ページで調べよう！といつも思っている。

IAM HTTPS API

サービスに HTTPS リクエストを直接発行できる HTTPS API を使用して、プログラムにより IAM と AWS にアクセスできます。HTTPS API を使用する場合は、認証情報を使用してリクエストにデジタル署名するコードを含める必要があります。詳細については、「HTTP クエリリクエストを使用した IAM API の呼び出しおよび IAM API リファレンス」を参照してください。

IAM をプログラムからではなく、直接呼び出すために、IAM HTTPS API が利用できます。2 回くらい使ったことがあるのだけれど、なんで使う必要があったのか覚えていない。諸々の問題を考慮すると、出来る限り SDK を利用したほうがいいんじゃないだろうか。きっと、SDK がどうしても使えない環境だったんだろうけど、それがどういう環境だったのかは覚えていない。