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

AWSにおける認証の仕組みを活用する【第7回】

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

本連載ではこれまで、AWS(Amazon Web Services)を使った実用的なシステムの構築ポイントについて色々な角度から考察してきた。Webサイトの構築から既存システムの移行までである。そこで今回は「認証」を取り上げる。AWSにおける認証やリソースへのアクセス管理は、これまでのサービス提供経験に基づき安定した仕組みになってきている。AWSの認証におけるコアである「IAM(Identity and Access Management)」を中心にベストプラクティスを探っていく。

 昨今、認証技術に関する議論が盛んになっている。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グループ」を使った権限設定の例図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を使ってシステムを組み立てる際には頻繁に使うだけに、その使い方をマスターしておこう。

 IAMの重要な使い方の1つに「クロスアカウントアクセス」がある。実は、上記のマネージメントコンソールは、多重ログインができない。そのため例えば、複数のAWSアカウントを保持していると、それぞれのリソースにアクセスする際は、今入っているアカウントから一旦ログアウトし、そのリソースが所属しているAWSアカウントに改めてログインし直さなければならない。開発アカウント、ステージング、本番アカウントなどを頻繁に行き来する場合、非常に面倒な作業になる。アカウント数分のパスワード管理なども大変だ。

 これに対しクロスアカウントアクセスでは、別アカウントのIAMユーザーに対し、IAMロールで権限を発行できるため、「スイッチロール」という機能によってログアウトすることなく、他のロールでのアクセスが可能になる。

社外ユーザーのアクセスを管理する「外部ID」

 自社ユーザー以外のアクセス管理には「外部ID」を活用しよう。外部の開発会社などに自社のAWSアカウントへのアクセスを許可したり、逆に顧客企業や取引先など他社のAWSアカウントにアクセスする必要がある場合などに利用する。外部IDとは、クロスアカウントアクセス用のロールを発行する際に設定できる任意の数字列である。

 他社のAWSアカウントと自社のAWSアカウントを連結させる場合、契約している会社以外の要素からのアクセス、いわゆる“なりすまし”への配慮が不可欠である。例えば外部の開発会社にクロスアカウントでIAMロールを発行した場合、その開発会社は別のクライアントとクロスアカウントでつながっていかもしれない。悪意のある人が、その開発会社を通して自社アカウントにアクセスしたとしても、管理者はそれを識別できない(図2)。

図2:「外部ID」を使ったアカウント連携の例図2:「外部ID」を使ったアカウント連携の例
拡大画像表示
バックナンバー
クラウド活用パターン辞典〜Amazon Web Servicesを使い倒す!〜一覧へ
関連記事

AWSにおける認証の仕組みを活用する【第7回】本連載ではこれまで、AWS(Amazon Web Services)を使った実用的なシステムの構築ポイントについて色々な角度から考察してきた。Webサイトの構築から既存システムの移行までである。そこで今回は「認証」を取り上げる。AWSにおける認証やリソースへのアクセス管理は、これまでのサービス提供経験に基づき安定した仕組みになってきている。AWSの認証におけるコアである「IAM(Identity and Access Management)」を中心にベストプラクティスを探っていく。

PAGE TOP