関連するソリューション
マネージドサービス（運用・保守）
サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト 松岡 政之
こんにちは。CSS部エバンジェリストの松岡です。
30度を超える日が続いたり台風が近づいたりと夏真っ盛りといった感じですが、皆様いかがお過ごしでしょうか。
パソコンやサーバを稼働させ続けていると室温が35度を軽々と超えてくるので、クーラーの温度を25度以下とエコではない設定にされている方も多いはず。そこで、熱源であるサーバを手元から少しでも減らしたいという方にクラウドをお勧めしたいと思います。
今回はクラウドの中からAmazon Web Service（以下、AWS）を業務利用の観点、管理者の視点で触ってみた所感をご紹介します。
１．AWSとは？
AWSは皆さんご存知大手通販会社のAmazon.comが運営するクラウドサービスです。サービス内容で有名なものをピックアップすると、クラウド上に仮想マシンを払い出すことができるAmazon Elastic Compute Cloud（EC2）やクラウド上でストレージを利用することができるAmazon Simple Storage Service（S3）などがあります。
他にも数多くのサービスがありますので、何かやりたいと思ったらまずはサービスがあるか探してみるといいかもしれません。また、AWSは基本従量課金のサービスとなっており、クラウドサービスのメリットである初期投資の少ないサービスの利用が可能です。加えて、一部サービスには無料枠が設定されており、個人でも試しに無料で使ってみるということも可能です。
２．AWSのユーザ
AWSの利用を開始するとまずルートユーザが作成されます。このユーザはアカウントの範囲内でなんでもすることができ、もしルートユーザ情報が漏えいしてしまった場合、好き放題利用されて莫大な請求が…！なんてこともあり得るため、最初の設定をした後は基本的には使用しないことをお勧めします。可能ならばハードウェアMFAデバイスを有効化し、設定したデバイスを金庫等で管理できればベストです。
通常、サービスの利用や運用で利用するにはIAMユーザが使用されます。このユーザは契約アカウント内で自由に作成することができ、またポリシーを記述することで柔軟に権限を変更することができます。しかし、利用者にIAMユーザを払い出すと組織内で管理しなければならないアカウントがAWSを利用するユーザ分増えてしまいアカウントを管理する手間が増えてしまいます。
新しいサービスを導入するたびにアカウントが増えて管理が煩雑になる、というのは社内のIT管理を経験された方なら一度は遭遇したことがあるのではないでしょうか。そこで次項ではユーザアカウントを増やさずに（＝IAMユーザを作成せずに）利用者にAWSを使ってもらう方法として、社内にあるオンプレミスのActive Directory（以下AD）とAWSとの連携についてご紹介します。当然ですが、社内にADがあることを前提としています。
３．AWSのAD連携
AWS Directory Serviceを使用することでAWSとADを連携させることができます。これによって、AWSのコンソールにADユーザのアカウントでログインすることができるようになり、新たにユーザを作成しなくてもAWSを利用することができます。
この際、AWSにアクセスを許可するユーザは指定したADユーザのみに絞ることができ、また、ADのグループを直接指定することもできるためロールを分けることで部署やプロジェクト、役職等によって異なる権限を割り当てることも可能です。
さらに、同じユーザに対して複数のロールを割り当てることもできるため、誤操作等を防止するために、同時に複数のプロジェクトに参加しているユーザのプロジェクトごとの権限分けや、同じユーザが本番環境と開発環境を扱う場合でもそれぞれ異なる権限を割り振る、といったことも可能です。ただし、良いことばかりではなくデメリットもあります。
デメリット1：IAMユーザではRADIUSサーバがなければMFAは利用できない
IAMユーザではAWSのサービス内で利用できていたMFAですが、RADIUSサーバがなければ利用できなくなってしまいます。すでに社内でRADIUSサーバを使用している場合はいいのですが、新規に導入するとなると費用の面でも運用の面でもあまり現実的ではないという組織も多いと思います。
その場合は、ADの認証自体MFAを用いていなければ同じアカウントでの認証のため同じポリシーでの運用と割り切ってしまうのも一つの手段です。もしくは、EC2上に自前のRADIUSサーバをつくるか、Web上の有償MFAサービスを利用するといった手段もあります。
デメリット2：AWS CLIを利用する場合、アクセスキーが必要
これはコンソールアクセス時のID/パスワードにあたるようなものだと考えていただければわかりやすいと思います。IAMユーザなら直接ユーザに紐付いたアクセスキーを作成することができるのですが、ADユーザに対してはできません。では、ADユーザで利用する場合にどのようにAWS CLIを利用するのかと考えた結果、私の中では以下の3通りの答えにたどり着きました。
解決策：①CLI上から一時的なアクセスキーを生成する
②ロール引き受け用のIAMユーザを作成しアクセスキーを生成する
③AWS Single Sign-On（AWS SSO）を利用する
①についてはこの中では一番すぐに試すことができる方法だと思います。ただし、少しコマンドが複雑なため利用するごとに一時アクセスキーを払い出すのは少し面倒な気もします。
導入負荷：低、運用負荷：低、利用負荷：中、といったところでしょうか。
②の方法は、アクセスキーを持つIAMユーザを作成して、ADユーザで使っているロールを引き受けさせることで全く同じ権限で利用できるといった方法です。せっかくADユーザを利用することでIAMユーザを新規に作らないようにしたのに本末転倒ではないかと思うかもしれませんが、永続的なCLI利用を許可するには現状ではどうしてもIAMユーザが必要となってしまいます。
導入負荷：中、運用負荷：中、利用負荷：低、といった感触です。
この場合のポイントは、作成するIAMユーザにロール引き受け以外の一切の権限を持たせないことです。そうすれば、仮にアクセスキーが流出したとしても引き受けられるロールについての情報を知られなければそのアカウントでは何もすることができません。
③については、私自身直接の検証がまだ出来ていないため少し不明確な部分がありますが、2017年12月から提供が開始された新しいSSOサービスです。AWS SSOはSAML連携を用いて外部のWebサービスと連携し、ログインをAWS SSOで一元管理することができます。こちらを利用することで、AWS SSOのユーザポータルから一時的なアクセスキーを払いだすこともできるようです。①がGUIからできるようになった感じでしょうか。
最初にまずサービスの利用設定をする必要があるため、導入負荷：高、運用負荷：低、利用負荷：低、といった感じです。
ただし、AWS SSOはまだ米国東部（バージニア北部）のみでしかサービスが提供されていないため、東京リージョン等でAD連携をすでにしている場合、バージニア北部リージョンで連携を作成し直す必要があります。これについては今後の東京リージョン等他リージョンへの展開に期待ですね。
どの方法についても一長一短がありますが、選択肢があることはいいことです。運用する環境に合わせて適切に選択していきましょう。個人的にはAWS SSOがより発展していくことに期待しています。
４．まとめ
AWSはユーザとしては何でもでき、とても便利なサービスです。その一方、管理者としては便利な反面運用が大変な部分も多くあります。ただし、ユーザ権限など非常に細かく制御できるので、権限を作りこむことでセキュリティの面でもコンプライアンスの面でも味方にしてしまえば心強いサービスです。
今回はユーザの権限関連についてはあまり触れませんでしたが、また機会があればAWSのユーザ権限管理についてお話しできればと思います。
それでは、よいクラウドライフを。
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
