みなさま、こんにちは、こんばんはokzkと申します。
数年前にはAmebaの画像基盤でストレージを超ガンバッてた輩です。
今回は、内製の認証認可基盤のPERMANを紹介します。
PERMANって？
Permission Managerからとって、PERMANです。
(藤子不二雄先生の漫画とは一切関係ないです)
簡単にいうと認証/認可基盤ですが、難しい言葉でいうと、Identity Governance & Administration(IGA)に分類されるシステムです。
ユーザサービス向けではなく社内向けのサービスとなっています。
具体的にはRBAC(Role Base Access Control)を志向していて、なんか色々対応しています。
整理せずに、ざっと例を上げると以下のようなカンジです。
- SAML2(AWS, Google, AzureAD, Slack, GitHub, その他色々)連携
- OpenID Connect
- CIBAフローも実運用中
- WebAuthnによるパスワードレス認証
- FIDO U2FによるMFA
- Google Authenticatorなどの認証アプリ(TOTP)などによるMFA
- SMSによるMFA
- 古き良きパスワード認証
- 歴史的経緯によるLDAPインターフェイスの提供
あと、ステキなキャラもいます。
なんで内製しようと思ったの？
前身として「LDAP管理ツールとしてのPERMAN」というモノが存在していたのですが、前任者から引き継いだ際に運用が重かったのでカッとなってコンセプトからして全く別モノというレベルで作り直そうと考えたというのが一番大きな理由です。
Anger Driven Developmentってヤツです。
とはいえ、それだけじゃ全く説明責任は果たせないので、後付けも含めて課題感や理由、対応方法をでっちあげました。
経済的合理性
IDaaSなんて、世の中には色々あるわけですよ。あるんですけど、だいたい「ユーザあたり月数ドル」みたいな価格帯です。
(MFAとかのオプションを盛っていくとそれ以上になることも。。。)
一方、サイバーエージェントグループ全体で管理対象のID数は、私が引き継いだタイミングでも4桁後半でしたし、今では5桁に届いています。
それでIDaaSのユーザ単価を掛け算してみると……開発専任エンジニアを何人か雇用できるレベルの結構な金額になっちゃうというわけです。
そんなわけで、最低条件としての経済的合理性はクリアできているという状態でした。
運用容易姓
以前はLDAP連携していたOpenAMでAWSとのSSOを実現していました。
ところが、設定をやってみたことあるヒトには分かっていただけると思うんですが、IdP側のSAML設定ってクッソ面倒くさいんです。
SAMLなんて所詮XMLに署名して送りつけるだけなのに(暴言)、なんでこんな苦労せなアカンねん。
AWSアカウントだけでも数百あるっちゅーのに、SSO設定するのにWebUIでポチポチして、、、ってやってられるかいな！
というわけで、本当に必要なパラメータだけ抽出してYAMLで設定できるようにして、GitHubのリポジトリで管理するようにしたSAML IdPを実装しました。
設定追加/修正/削除はPull Requestを送るだけ、という風に社内にはオープンになっています。
テストも自動化できるし、レビューでチェックもできるし、履歴も残っているので、誰が依頼したかも明確です。
ちなみに、世間のIDaaSでも、SSO設定は当時のOpenAMと比較したら簡単になってます。
ですが、だいたいIdP側の設定は管理者によるオペレーションが必要なので、どうしても依頼ベースの運用になりがちです。
PERMANではPull Requestベースの運用のおかげでIdPの規模が大きくなっても、管理者の負荷を避けることができています。
アクセスコントロールの管理の徹底
仕組みとしてSAMLなりOpenID Connectを実装するのは、それなりに頑張れば、それなりにできるわけですけども、本当にシンドイのは「誰がアクセスしていいか」というアクセスコントロールの運用です。
数千人規模のIdPになると「アクセスコントロールを特定の管理者が全部管理する」という運用が現実的ではない規模感となります。
そのため各部署/サービスに管理権限を委譲する必要があります。
一方で、弊社は事業のアジリティが異常に高いせいで、部署や子会社が出来たり無くなったりや、ヒトの異動が頻繁に発生するわけです。そうすると
- アクセスコントロール管理の引き継ぎをミスって、
- 棚卸しがされなくなり、
- そのうち棚卸ししていいかの判断ができなくなり、
- 「動いているモノは触らない」方針になる。
というステキなコンボが成立しちゃいます。
だからといって「事業のアジリティを落とせ！」なんて言えるわけもなく、なんとか仕組みで解決しなきゃアカンということで、PERMANでは思想として、以下のようにRBACのロールやアカウントそのものの棚卸しが強制される仕組みにしています。
- あらゆるところに有効期限があるようにして、棚卸しは自動化されるようにする。
- 自動で棚卸しされないよう、継続利用が必要なモノについてはちゃんと管理してもらう
- 完全手動管理だとそれはそれで運用が死ぬので、ルールベースで有効期限延長を自動化する仕組みも用意
要は「棚卸しをしたい」というモチベーションを現場に期待せず、「業務で必要な権限が欲しい」というモチベーションを利用するようにしている、ということですね。
外部SaaSのユーザ管理
SAMLやOpenID Connectでは認証はカバーできるのですが、外部SaaSの中にはさらにユーザのプロビジョニング/デプロビジョニングが必要になることもあります。
PERMANではロール管理周りのインターフェイスをgraphqlで実装し、SCIM等を提供しているSaaSのユーザ管理をPERMANのロールと対応させる仕組みの実装を容易にしています。
前述の通り、ロールは一定のレベルでユーザ管理ができている状態が保証されるので、外部SaaSのユーザ棚卸しを担保できるようにできます。
新しい仕様の実装へのチャレンジ
内製だと目新たらしい標準にも率先して対応できます。具体的に対応したのはFIDO U2FやWebAuthn対応、OpenID ConenctのCIBAフロー対応などです。
(CIBAについては、実運用に乗せている会社はウチ以外、まだ殆どないんじゃないかと思います)
こんなカンジで先行して社内で実験的に実装にチャレンジできているということは、ユーザサービスにおいても採用のハードルが下がって選択肢を増やすことにつながります。
他の業務との関連性
私はセキュリティ部門に所属しているため、IdPの開発の他に、サービス部門から認証/認可について相談を受けることがあります。
そのときに「いろんな標準をキャッチアップしていて、いくつかメジャーどころは実装している」というのは、安心感や説得力が違います。よね？ たぶん。
まとめ
社内向けに提供しているPERMANという認証/認可のシステムについて紹介しました。
ここ数年で対応サービスも増えてきて、ありがたいことに社内の認可周りのデファクトスタンダードになりつつあります。
これまではほとんど社外に情報公開していませんでしたが、今後は情報公開も進めていきますので興味をもっていただけると幸いです。
あと、世間のIDaaSを採用しなかった理由をいくつか書きましたが、だからといって安易に自作に走るのはオススメできません。修羅の道です。
対象IDの数にもよりますが、まずは既存のIDaaSを利用して、運用辛くなってから次のアクションを考えるほうがよいです
それではよい年末を！