トレタ開発者ブログスマートフォン用の表示で見るトレタ開発者ブログ飲食店向け予約/顧客台帳サービス「トレタ」、超直前予約アプリ「トレタnow」を開発・提供するスタートアップ企業です。2019の16日目の記事です。趣味はNFL観戦とボルダリングです。NFLは今年11月にマイナス気温の屋外で現地観戦してきました。最近リードクライミングの講習を受けまして、ガシガシと岩を登っております。SSOのお話をしようと思います。参考に実施したことで発生した金銭・セキュリティ等あらゆる問題について責任を負いかねますので、自己責任のもと実施していただくよう、よろしくお願いいたします。誤り等あればはてブ等でご指摘いただけますと幸いです。入社直後の状態トレタはしばらくインフラ担当者がごく少数な時期が続いたこともあり、いろいろ改善しないといけないところがあるな、というのが入社直後の印象でした。AWSアカウント構成の改善はすぐに取りかかれそうだと思ったので、着手することにしました。当時の状況はこんな感じです。本番アカウントが親アカウントとなり、ステージングアカウントと一緒に利用料金を支払っている監査ログは本番アカウントで保管されている検証用にリソースを作成する場合はステージングアカウントに作成するインフラ担当者がそれぞれのアカウントに社員ごとにIAMユーザを作成し、クレデンシャルを払い出す図に起こすとこんな感じですおそらくAWS利用初期の組織はこういった運用をされている企業が多いと思います。ある程度規模が大きくなり運用年数も経っていたトレタでは、以下のような問題が起きていました。ステージングアカウントで検証用のリソースが放置され、プロダクトとして利用されているのかどうかわからないこれにより、何人もうかつにAWSリソースを触ることができないよって、AWSのオペレーションがインフラ担当者に集中し、権限移譲が難しい状態に陥っていたIAMユーザについて、本番アカウントとステージングアカウントで管理上のズレが発生している本番環境と監査ログ保管が同居していることで様々なリスクがあるちなみに本番アカウントのアカウント名も人の名前になってたりして歴史がありますね笑とくに「うかつにAWSリソースを触ることができない問題」「本番環境と監査ログ保管の同居」については早急になんとかするべきだと判断し、まずはAWSアカウントをきちんと構造化して、プロダクトが運用されているアカウントに検証用リソースを作らなくてもすむ、監査用のアカウントを作成し監査ログを別にできるような状態にしようと思いました。おけるマルチアカウント管理の手法とベストプラクティス」というセッション名でAWSの高田様が登壇されております。以降がわかりやすくておすすめです。Organizationを利用し以下のアカウントに分けることにしました。AWSのサービスをお試しで利用したいというときに使うアカウント。各アカウントのCloudTrailログ等監査に関するログを保管するアカウント前職でのAWSアカウント運用経験から、将来情シス用のアカウントが必要になるだろうと予想していますが、近い将来に関してはニーズがないと判断し一旦作成対象から外しました。Organizationを利用すれば、秒でアカウントを作成できるのでそのときに作れば問題ありません。プロダクトのアカウントに情シスのリソースを作ってしまうと移行がマジで大変なのでみなさん気をつけましょうアカウント構造化に合わせてアカウント名やメールアドレスもきちんと規則性をもたせるようにし、誰がみても理解できるような状態を目指した結果、以下のようになりました。(メールアドレスは伏せさせていただきます)これにより、当初望んでいた「プロダクトから隔離された好き勝手触れるAWSアカウント」と「監査用の専用のAWSアカウント」の用意が完了しました。ここではCloudTrail等のログを中央集権アカウントに集約する設定については割愛します。ググってくださいおまけ:支払いアカウント切り替え今回の構造化に伴い、AWSの支払いアカウントが本番アカウントから支払い用アカウントに変更となりました。AWSの営業担当の方にアドバイスをいただき、以下の手順に沿って実施しました。Organizationに本番アカウント、ステージングアカウントを招聘、完了(この情報については記事冒頭の免責事項も合わせてご確認ください)2実行後〜3実行前まで、AWSアカウント単体で請求が発生するためご注意ください。私は事前に社内経理担当者に連絡しており、スムーズに作業ができました。SSOの導入さて、上述の通りAWSアカウントを細分化することができましたが、各AWSアカウントへのログインに関して問題が見え始めました。社内のエンジニア全員に検証環境を触ってほしいと言いつつ、検証用アカウント用のIAMユーザを発行する運用負荷やAWSのアカウント切り替え作業など、煩雑な作業がさらに増えてしまいました。On(SSO)を導入できないかと検討し始めました。前職ではとあるIDaaSのSSO機能を利用してAWSにログインしており、SSOの管理画面上で各AWSアカウントへのフェデレーションログインを設定することで、容易にAWSマネジメントコンソールにログインできるような環境ができていました。「1度SSOのログイン時に認証するだけでSSOのポータル画面から様々なAWSアカウントにクリックするだけでログインできる」という状態です。現在残念ながら社内にSSOを導入できていないため、こういった状況には至れていません。SSOを試験導入(後に本採用)することにしました。現状、社内でActiveDirectoryやLDAPを運用していないため、ミニマムスタートということでAWSのSimpleADを利用してSSOのユーザ管理を行い、利用を開始しました。設定についてはAWSのドキュメントを参考にして作業した以上のことをやっていないので説明は割愛します。SSOにログインするとOrganizationsに紐づくログイン可能なアカウント一覧が表示され、マネジメントコンソールへのログインや一時クレデンシャルの払い出しをすることができます。SSOにログインすればセッションが切れるまでの間はアカウントの切り替えは容易です。都度IAMユーザログイン時の多要素認証をする必要はありません。前職で利用していたIDaaSのSSO機能では、「SAML認証するためにAWSにIDプロパイダーを作成し、ログイン後にどのIAMロールにAssumeRoleするか」という項目を設定する必要がありました。そのため、新しいAWSアカウントを作成するとログイン後に適用するIAMロールを作成するSSOにアプリケーションを作成する&SAMLメタデータドキュメントのダウンロードするAWSにIDプロパイダーを作成するIDプロパイダーにSAMLメタデータドキュメントを登録するSSOのアプリケーションにIDプロバイダーおよびIAMロールを設定するといった作業が必要でした。OneLoginの設定について、Serverworksさんの以下の記事をご覧いただくとイメージがわくかもしれません。http://blog.serverworks.co.jp/tech/2018/06/22/onelogin-aws-saml/この作業はある程度自動化できるとはいえ、(IDaaS側のAPIが不十分なこともあり)SAMLメタデータドキュメントの交換は自動化できず、ちょっとした運用負荷がありました。SSOポータル画面からAWSにログインすることができます。SSO側でIAMポリシーを一括管理しています。SSOとAWSログインアカウントを紐付ける作業を実施すると、アクセス権限セットに登録されたポリシーを元にAWSログインアカウント側でIAMロールが生成され、IDプロバイダーの生成・紐付けもやってくれます。細かなリソースの管理は難しいですが(後述)、SSOにログインするユーザのグループをある程度まとめられるならとても便利な機能となっています。トレタでの現状のログイン先アカウントとアクセス権限セットについては、各職種ごとにグループを作って以下のように分けています。(やや不正確なところはありますが概ねこのとおりです。SSOはユーザ管理DBにSimpleADを利用するとEmailで認証コードが送られる形式の多要素認証しか選択できませんでした。ログインするたびにメールの受信箱を確認し番号をコピペするという作業が必要でした。Authenticatorなど)を利用した多要素認証を設定することができることを気づきました。SSOを使い始めてから切実に願望していた機能のひとつです。SSO稼働アカウント(要は親アカウント)のマネジメントコンソールにログインし、ボタンポチですぐにできます。認証アプリを利用しない場合でも多要素認証を強制でき、その場合はメールアドレス宛に認証コードを送信する管理者だけでなくユーザ自身が認証アプリを登録することが可能という設定が織り込まれています。新入社員用等に、SSOユーザ作成時はメールアドレスによる認証で設定しておき、本人が望めば認証アプリを自分自身で設定してもらうというルールにしておくことで、SSOユーザも管理者も楽な状態を維持することができました。v2のインストール方法」について紹介された記事が上がってきました。このときは「ふーん、Pythonがバンドルされるのか」ぐらいの気持ちでしかなかったのですが、直後に驚きのリリースが発表されました。コピペするという運用をしており、作業の手間とプロファイル名書き換え等による事故のリスクを抱えた状態で運用していました。使うやや黒魔術的な取り組みをしてたりしました。説明がめんどくさいので、気になる方は勉強会等で捕まえていただければお話します。SSOの連携機能を使ってみて利便性は格段に向上しました。同等のことを実現しています。打つことでブラウザの認可画面に遷移し、許可ボタンを押すとSSOのアクセストークンが発行され、そのアクセストークンを使ってフェデレーションログインを実現しています。SSOへのログイン画面を通過した後にこの認可画面が表示される。cli(v2)の実行コマンド。SSOの画面から一時クレデンシャルをコピペする作業が必要となります。SSOへ参画させる株式会社トレタはトレタCC株式会社(以降トレタCC)という子会社をもち、トレタCCのサービス展開にもAWSを利用しています。Organizationには所属していません。そのため、トレタCCにログインする必要のある社員にのみIAMユーザを発行しているという状況です。トレタアカウントとトレタCCアカウントの両方を行き来する社員も存在するため、可能な限りログインの窓口を1つに絞りたいと考えています。この状況は多くの会社に当てはまるのではないでしょうか。SSOでは、Organizationに紐付いたAWSアカウントだけでなく、Organization外のAWSアカウントにフェデレーションログインすることも可能のようです。ProviderやSAMLメタデータアップロードなど、通常のSAML連携の設定を実施すれば連携可能だと思われます。SSOの連携は実施していません。社のポリシーや法務・経理周りの許可がおり次第実施する予定です。IAMでは、これまで多くの利用者に利用されてきたRBAC(ロールベースアクセス制御)だけでなく、ABAC(属性ベースアクセス制御)を提唱しはじめました。これは、今まで「ロールやユーザごとにポリシーをわける制御」であったのが、「ユーザやロールで同じポリシーを共有し、IAMとリソースに付与されたタグ(属性)の一致をもって制御する」という方式です。Tagsを利用する必要があります。Tagsの説明はクラスメソッドさんのブログに詳しく記載されていますので、そちらをご参照ください。SSOでABACを実現することは難しいです。アクセス権限セットによって作成されるIAMロールにタグを付与することが現状できないSessionTagsを利用するためのSAMLアサーションの属性情報を設定できないという状況のためです。AWSアカウントが少なければ、自動生成されるIAMロールを追従してタグを付与することでABACを実現できますが、AWSアカウントやアクセス権限セットの組み合わせが多くなるととてもじゃないけど運用が回りません。Tagsサポートがリリースされるだろう」という予想のもと、一旦リソースに特定のタグを付与することで「ABACっぽい記述のRBAC」を実現しました。Managerを特定のEC2にのみ実行可能」を考えます。いうタグを対象のEC2インスタンスに付与し、アクセス権限セットのポリシーの一部(ステートメント)を以下のように設定しました。Managerでログインでき、そうでないインスタンスにはログインできないことを確認しました。現状まだ実務での利用に至れていませんが、対象のリソースにこのタグを付与したり許可アクションを設定できれば、実運用を始めようと考えています。置き換えることで同様のことができると思われます。)この検証で思い当たる点、気をつける点についてわかったことがあるので以下にまとめます。リソース側のタグ管理は、できるだけコードベース管理されていることが望ましいです。最近だとTerraformやCloudFormationを利用してリソース管理をされている方が多いと思いますが、ABACを実運用する上で必要になると感じました。ポリシーのステートメント文内で利用する条件キーが、AWSサービスによって異なる点に気をつけてください。各アクションと条件キーの対比については、以下のページに各サービスごとにまとまっていますので、ポリシーを作成するときに参考にしてください。条件キーが必要になります。条件キーがなかなか厄介で、この条件に合致した場合アカウント内のあらゆるS3バケットにPutObjectできてしまうということを観測しました。そのため、どうしてもポリシー側でリソース名を記述必要があると判断し、一旦PutObjectを否認するようにしています。専用ロールになってから作業するという逃げ道を考えています。SSOを導入したお話について執筆しました。SSOを導入するべきだと思われる状況について私見を述べます。「AWSアカウントが5以上あり、ログイン用アカウントからSwitchロールして目的のアカウントにログインしている」という組織の方にはおすすめしたいです。SSOを利用することでコネクター設定の作業負荷が軽減できるかもしれません。SSOの設定作業が非常に楽だと感じました。SSOで他はIDaaSのSSO、といった使い分けをすることも視野に入れておけばよかった、という気持ちもあります。Directoryと連携することができるため、ぜひ検証してみてください。SSOを導入したら相当楽になるはず!」と直感しました。ご検討いただけますと幸いです笑(と言いつつ免責事項をご確認の上、きちんとご調査いただきますようよろしくお願いいたします。アカウントレベルで制限したいアクションをアクセス権限セットで封じるのはかなりめんどくさかったので、大変参考になりました。これとABACを組み合わせることでいい感じのアクセス権限払い出しができそうな気がしています。SSOのポジティブな話を記載してきましたが、もちろん問題もあります。SSOを設定できません。SSOの検証・実験のハードルが高いことが問題点であると感じました。完全に独立したアカウントを用意すれば検証は可能ですが、稟議・経費精算といったワークフロー上の手間が増えることになります。ひとつは、前述の通りABACが現状難しいことと、アクセス権限セットのポリシーをコードベース管理できないことです。前者はおそらくそのうちリリースされるとして、後者は管理のためにAPIの提供を望みます。現場のエンジニアが片手間でSSOを設定することは負担が大きく、せめてユーザ管理をActiveDirectoryやLDAP等を利用して情シス側に移管できればと思っています(何卒宜しくお願いします)。最後にアドバイスとして、組織の運用を大きく変えるような仕組みを導入したいときは「まず自分を生贄に捧げる」という覚悟を持って取り組むと、それを運用し始めたときの利点欠点の理解が進みます。SSOに寄せることで良い点・悪い点を実感として得ることができ、これらを同僚に共有することで本当に導入すべきかどうかをきちんと議論できたと思います。終わっているはずで、その試合の結果次第では地区優勝に大きく近づきます。Packers勝利&Rams敗北でプレーオフが確定しました!残り2戦のうち1勝すれば地区優勝です。プレーオフに向けて不安要素がかなり多い(とくにラン守備とフリーになれないWR陣)ですが、1発勝負ぜひ勝ってスーパーボウルに行けたらと思ってます。2019に参加してきました!こんにちは。2018の24日目の記事です。2017に参加してきましたiOSエンジニアの高です。去年に引き続き、今年もiOSDCに参加し...2017-01-20トレタのRailsを4.2にアップグレードしましたサーバサイドエンジニアの中村です。»トレタ開発者ブログ飲食店向け予約/顧客台帳サービス「トレタ」、超直前予約アプリ「トレタnow」の開発メンバーによるブログです。Blogスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。