SSOを実現するOneLoginのメリット
続いて登壇したサーバーワークス情報システムの宮澤慶さんは、「AWSをより安全に使うためのID管理」を語った。
サーバーワークス情報システムの宮澤慶さん
宮澤さんは、さまざまなデバイスからクラウドサービスを使える一方、複数のクラウドを使うと管理が煩雑になるとID管理の課題を語る。また、複数のアカウントで共通のポリシーが適用できないというのも課題の1つだ。
これを解決するのがサーバーワークスが導入している「OneLogin」だ。OneLoginでは1つのIDで複数のサービスをログインできるSSOを実現できるほか、共通のパスワードポリシーを適用できる。エンタープライズ環境で導入の多いActive Directryとの同期も可能で、LDAPやGoogle Apps、Workdayなどとも連携する。コンプライアンス面でも有効ですべてのユーザーの変更とアクティビティを記録し、後追いで監査することも可能。さらに、CSVをインポートすることで、BIツールでの可視化もできる。
OneLoginではID・パスワードの代理入力ができるほか、ID連携プロトコルであるSAMLを用いたSSOが可能になる。OneLogin経由でAWSにログインすると、SAML用のIAM Roleを利用してユーザーがコンソールを利用できるため、CloudTrailで認証証跡をユーザー別に簡単にとることができる。裏では相当複雑なシーケンスになっており、認証や認可の要求、権限確認、操作記録などが各コンポーネント間で行き交っているという。
OneLoginの背後でSAML認証のための複雑なシーケンスが動いている
OneLoginでは運用する側も恩恵を受けられ、ユーザー側もID・パスワードを知らないで使える。とはいえ、OneLoginのアカウントが漏えいすると、すべてのサービスが利用できてしまうため、多要素認証の導入が必須だという。宮澤さんは「MFAで認証を強化するのはもちろん大事。それに加え、うちの会社はOneLoginでSSO環境を実現し、認証をシンプルにした上で、そのアカウントをMFAで守るということをやっている」（宮澤さん）。
AWSアカウントを分割してもデメリットはあまりない
「AWSアカウントを複数に分けるメリットとデメリット」というタイトルで最後に登壇したのは、AWSJのパートナーソリューションアーキテクトの小梁川貴史さん。もともと4年くらいはユーザーとしてAWSを利用していた立場で、JAWS開催のタイミングがAWSに入社してから満1年になるという。
AWSJ パートナーソリューションアーキテクト 小梁川貴史さん
AWSを使ってパートナーと開発やプロダクションを行なう場合、1つのアカウントだとなにかと不都合が多い。「開発環境には広い権限を与えないと必要なロールの検証ができないし、IAMでロールをいちいち付与するのは面倒。でも、プロダクションは誤操作を防ぐために権限を絞りたいけど、正社員は権限を持たせ、協力会社は参照のみにしたいというケースも多い」と小梁川さんは語る。
また、1つのアカウントで複数のプロジェクトを抱えると、他のEC2やSecurity Groupが見えてしまうため、誤操作の可能性もあるし、課金の按分も面倒になる。さらにサポートやメンテナンス通知に関しても、複数のプロジェクトが混在すると煩雑になる。その他、LambdaやAPI Gatewayなどアカウント当たりのスロットやリクエストが決まっているサービスの場合は、性能面での制約につながってしまう。こうしたデメリットを考えると、アカウントを分けるという考え方も取り入れたほうがよいようだ。
最近ではアカウントをまたいだ運用も楽になっている。たとえば、AMI（Amazon Machine Image）に関しては、以前はアカウント単位で作成しなければならなかったが、今ではアカウントをまたいだコピー機能が利用できるようになっている。また、DBに関しても以前はダンプから複製しなければならなかったが、現在では他のアカウントからスナップショットを複製できるようになった。「アカウントを複数またぐことによって生じていたデメリットは、昨今解消されつつある」と小梁川さんはアピールする。
アカウントを超える機能が充実してきている
また、コストに関しても「Consolidated Billing（一括請求）」という概念が導入されており、支払いアカウントを1つにまとめることができる。経費処理的には1回の処理、1枚の請求書で済み、複数にまとめるとボリュームディスカウントのしきい値を超えられるので、コストメリットも大きい。RI（Reserved Instance）に関しても、同一リージョン、AZ、サイズという条件で転用することが可能になるため、損することはないという。
一方でデメリットもある。まずは複数のアカウントがまとめられて平均値化されるので、RIの割引なども含め、アカウントごとの厳密なコスト換算がやりにくくなること。また、ルートアカウントが多数できることになるので、運用や権限委譲のルールを厳密に統制する必要がある。そのため、各アカウントのオーナーは責任を持ってIAMを運用しなければならない。
個人的には分割推進派だという小梁川さんは、実際の運用イメージを示した。まずチーム内で開発用とプロダクション用でアカウントを分割しつつ、支払いアカウントを統合。さらに監査用のアカウントを作り、CloudTrailで取得したログなどをまとめてS3バケットに収めるのがオススメだ。このやり方だと、「会社の監査のやり方が変わっても、バケットは1つなので、チェックのやり方を1箇所変えればいい」（小梁川さん）というメリットもある。
アカウント分割の利用イメージ
小梁川さんは、「アカウントを割ることは権限分割の第一歩。もちろんIAMでできることも多いけど、共有アカウントの中で権限を変えるより、アカウント自体を分けることで、権限を明確にし、チーム間の依存をなくすことができる。セキュリティの第一歩ということで、アカウントを分割することを検討してはいかがでしょうか？」と語り、将来的なアカウント分割の検討や分割時のコスト換算に関する情報収集、タグ付けの徹底などをアピールし、セッションを終えた。
このように夢物語だけではないAWSの運用現場での苦労や工夫が満載のOpsJAWS。都内でも特に活発に活動しているユーザーグループの1つなので、興味があるユーザーはぜひ参加してもらいたい。
