OneLoginからAWSコンソールにSSOできるようにした話
はじめまして、情報セキュリティ部の新藤です。今回はOneLoginを活用したAWSアクセスの運用方法について紹介したいと思います。
はじめに
MICINではIDaaS（ID管理基盤）としてクラウドサービスの「OneLogin」を使用し、SAML認証などを利用して各種クラウドサービスにシングルサインオン（SSO）できるようにしたり、多要素認証を導入することで認証の強度を高めています。
現在、私は社内利用している各種サービスの個別の認証をOneLoginのSAML認証に切り替える作業に取り組んでおり、その一環で、AWSの管理コンソールへのログインを、AWSの個別の認証から、OneLoginを経由のSAML認証に切り替えてみました。
本記事では、切り替えの前と後での処理の違い、実際の設定に用いたTerraform、切り替えにあたって社内のエンジニアから挙がった疑問点等（一般でいうFAQに相当）をご紹介します。
もくじ
- 認証方式の切替前後の処理概要
- 環境構築方法（Terraform）
- MICINエンジニアからあった疑問点などなど
認証方式の切替前後の処理概要
OneLoginとAWSの設定の説明に入る前に、まずは切替前後のMICINのAWSコンソールへの既存のログイン方法の概要を簡単に説明します。
Before（踏み台として管理用AWSアカウントを利用）
IAMユーザー作成権限のみを持った管理AWSアカウントにIAMユーザーを作成し（Terraformを利用）、IAMユーザを払い出されたエンジニアは管理AWSアカウントを経由して各種本番環境や開発環境に対してロールスイッチでAWSコンソールへアクセスしていました（下図）。
しかし、この運用方法ではいくつか問題点がありました。それは、
- 管理者はエンジニアの出入りがある際にTerraformでIAMユーザー作成・削除を行う必要があり、非エンジニアにはTerraform作業に必要な環境の整備やそもそもの仕組みの理解にかかる敷居が高い。
- この作業自体が本番AWS環境の変更に相当するため、変更管理にかかるレビューなどの負荷がかかっていた。
- IAMユーザーをエンジニアに払い出すときに、管理者がエンジニアにパスワードを連携するが、そのパスワードの管理方法が煩雑になりやすく、漏洩のリスクが付きまとった。
という点です。こうしたことから、この一連の作業は慣れていたとしても5–10分程度かかるため意外と手間もかかっていました。
After（OneLoginのSAML認証で各環境にSSOログイン）
変更後は、管理者がOneLoginの管理画面でアクセスを許可したいユーザにIAMロールを付与し、エンジニアはOneLoginの画面からSSOすることで各種本番環境や開発環境のAWSコンソールにアクセスできるようになりました（下図）。
これによって、
- そもそも本番AWS環境の変更が必要なくなった。
- 管理者はエンジニアの出入りがある際にはOneLoginで適切なロールをエンジニアに付与するのみでよくなり、非エンジニアでも難なく対応可能になった。
- AWSコンソールヘのアクセスをOneLoginが払い出されているユーザに自明で限定できるようになり、アクセスコントロールも強化された。
- エンジニアはAWS個別のID/PW（+α）認証を必要とせず、OneLoginの画面からボタン一クリックで（SAML認証により）ログインできるようになった（ユーザ側のパスワード管理負荷軽減）
となり、管理AWSアカウントが担っていた役割が、より効率の良い形でOneLoginに移管されています。
環境構築方法（Terraform）
ここからは、OneLoginのSAML認証で各環境にSSOログインできるようになるための環境構築の方法について説明します。
大まかな手順としては、
- OneLoginでAWSコンソールログイン用のアプリケーションを作成
- AWSでSAML IdPの設定
- AWSでロールを作成
となります。
これは、普通にやればOneLoginの管理画面（GUI）で設定することは可能です。ただ、当社の場合は、アカウントが数十あり、それぞれに複数のロールがあるため、これらの数を手作業でやるのはすごく大変です。
このため、今回は、構成管理で広く利用されているTerraformを活用して、自動で作成されるようにし、また、変更などが発生した場合のOneLoginやAWSの環境の整合性が自動で維持されるようにしました。
作成したTerraformのあるリポジトリはこちら。
手順や実行コマンド等はGitHubリポジトリのREADMEに記載しました。
Terraformの実行が成功したあと、作成したAWSロールにOneLoginからアクセスできるように該当ユーザーにOneLoginロールを付与する必要があります。こちらもTerraformで実行しても良かったのですが、そうすると、そもそもすべてのユーザ更新にTerraform作業が入り、元々の運用上の問題がが残るので、各ユーザへのロールの付与はOneLogin管理画面からおこなうように運用を設計しました。
Terraform実行のためのCredentials取得が大変でした・・
Terraformを実行する前提として、各アカウントのAWS Credentialsを取得しておく必要がありますが、認証方法をSAMLするべきAWSアカウントが多い場合は、この取得にかなり手間がかかり、取得作業についてはどうしても手作業が必要となってしまいます。自動化する策を色々とチーム内で考えましたが、良い案が思い浮かびませんでした。。。というわけで、Credentialsは人海戦術で取得しました。
エンジニアからの疑問点
今回の切替えの過程で、MICINのエンジニアから挙がった質問を紹介します。
みんな同じロールでログインするのに、個人を識別することはできるの？
個人を識別することは可能です。OneLoginからAWSコンソールにアクセスするとログイン情報は以下の画像の通りとなります。AWSコンソールの右上のユーザー表示ではちゃんと個人を識別しているのがわかりますね。
また、AWSアクティビティログにおいても個人を識別していることがわかります。Elastic Searchにおいて上記ユーザーのアクティビティログを確認できます。
ログで個人を識別することができるため、ログ監視は今まで通り行うことができます。
AWS CLIを実行したいときのアクセスキーとシークレットキーの取得の仕組みはどうなってるの？
OneLoginがオープンソースとして提供している、AWS IAMのアクセスキーとシークレットキーを取得するCLIがあります。こちらを用いることによって、CLI上でOneLoginの認証を行うとAWS IAMのアクセスキーとシークレットキーを入手することができます。
https://developers.onelogin.com/api-docs/1/samples/aws-cli
CLIは以下のプラットフォームで使用することができます。
それぞれのリンク先のリポジトリのREADMEを参照し、CLIを実行してください。ちなみに、Dockerを用いる場合とPythonを用いる場合とで全く同じソースコードを用います。したがってDockerとPythonについては全く同じリポジトリへのリンクが貼ってあります。
アクセスキーとシークレットキーのセッションの有効時間はどうなるの？
上記で挙げたOneLoginが用意しているCLIを用いて取得したアクセスキーとシークレットキーのセッションの有効時間は最短で1時間、最長で12時間となります。この値はTerraformで変更可能です。
MICINでは本番環境やステージング環境ではセッションの有効時間を短め、開発環境では本番環境などよりは短めに有効時間を設定をしています。上記のように環境ごとにセッションの有効時間を分けると利便性とセキュリティをどちらも高めることができるかなと考えています。
セッションが切れた際の挙動はどうなるの？
セッションが切れた場合はそのアクセスキーとシークレットキーを用いてAWSの各リソースを扱うことはできません。セッションが切れた際はもう一度CLIを実行し、アクセスキーとシークレットキーを取得し直す必要があります。
おわりに
1ヶ月使用してみて感じたこと
最初にSAMLの設定をする際に各環境ごとにAWS Credentialsを取得するのはかなり骨の折れる作業でしたが、一度設定してしまえばその後の運用はかなり楽なものとなりました。
AWS利用者としては、OneLoginにログインし、AWSのボタンを押すことでAWSコンソールにログインできるようになったためAWSへのアクセスが簡便になりました。
また、社内ITの管理者としては、AWSを使用する際にはコンソールログイン・CLIの利用問わずOneLogin経由でのみとなったことで、それぞれのエンジニアの認証についての心配事が少し減ったことは良かったです。
