[クラウド活用パターン辞典〜Amazon Web Servicesを使い倒す！〜]

2017年6月5日(月)清野 剛史（クラスメソッドAWS事業部ソリューションアーキテクト）

リスト

　昨今、認証技術に関する議論が盛んになっている。Yahoo！がパスワードを廃止しワンタイムパスワードに変更したり、LINEが生体認証などを利用した新しい認証技術を模索する団体である「FIDO Alliance」に加盟したりなど、「脱パスワード」の動きが進んでいる。海外ではアメリカ政府が「パスワードの定期的変更を推奨しない」と提言し、代わりに文章によるパスワードである「パスフレーズ」を推奨し始めた。

　他にも、アメリカの空港では生体認証によるログインが行われ、イギリスのHSBC銀行ではパスワードの代わりに声紋認証による口座へのアクセスを可能にしている。もちろん日本の銀行でも指紋や静脈といった生体認証をATM（現金自動預払機）に導入してきた。このようにパスワードを前提とした認証技術は今、過渡期を迎えていると言える。

「ユーザー」「グループ」「ロール」の3通りで権限を管理

　そうした中で、AWSにおける認証の核になるのが「IAM（Identity and Access Management）」である。まずは、このIAMの基本を抑えよう。IAMは大きく「IAMユーザー」「IAMグループ」「IAMロール」に分かれている。それぞれにAWSリソースへの権限を与えられるが、なぜユーザーだけでなく、グループやロールが設けられているのだろうか。

　グループは、複数のユーザーに共通の権限を与えることを想定している。例えば、システムの開発過程では、複数のユーザーが関与する。その際、IAMユーザーのそれぞれに権限を振り当てるのは手間がかかる。IAMグループがあれば、「開発者」や「テスター」「管理者」「マネジメント」といった役割ごとにIAMグループを作り、そこに権限を振った上で、そのグループに個々のIAMユーザーを所属させられる。こうすることで、役割ごとに権限を一括変更したり、ユーザーをグループに入れたり外したりすることで簡単に権限を変更できるようになる（図1）。

図1：「IAMグループ」を使った権限設定の例
拡大画像表示

　これに対しIAMロールは、人間や外部デバイスではなく、リソースサービスに対してAWSリソースの権限をつけたい場合に利用する。IAMロールを理解するには「Assume Role（役割の移譲／引受）」について理解する必要がある。

　Assume Roleは、ユーザー以外の“何か”を信頼し「その何かが自分に対してアクセスすることを許可する」というものだ。Assume Roleで特定のIAMユーザーを信頼すれば、そのユーザーにのみ権限が振られる。AWSアカウントを信頼すれば、そのアカウントがAWSの、どのリソースに対し、どんな行動を許可するのかを決められる。例えば、Facebook IDを信頼すれば、AWSはFacebook IDを持つユーザーに対しAWSへのアクセスを許可／拒否ができる。

リソースの操作はすべて「マネージメントコンソール」で設定

　IAMロールの最大の特徴は「特定のAPI KEY／SECRETを持たない」という点だ。どのAWSサ―ビスから、どのAWSリソースに対する操作であるかは、すべて「マネージメントコンソール」で設定する。これにより、権限の元になるKEY類が外部に出ることがないため、ヒューマンエラーを起こさずに権限の受け渡しができる。この機能は、AWSを使ってシステムを組み立てる際には頻繁に使うだけに、その使い方をマスターしておこう。