この記事は「Goodpatch Advent Calendar 2021」と「corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#2」と「Okta Advent Calendar 2021」の17日目の記事です。遅れてすみません！
グッドパッチでシステム管理者を担当している @enpipi と申します。
共有アカウントはセキュリティの観点からもアンチパターンでそれをなくす為のSSOですが、 サービスそのものがアカウントを共有する前提である場合もあり撲滅できないケースもあります。 note.com
撲滅できない共有アカウントをOktaのSWAを使って管理してよかったこと・今後に期待することについて考えたことを共有します。
共有アカウントの管理問題
共有アカウントを管理する際の課題の1つに、アクセス権の管理が上げられます。
- 社内の決められたメンバーにだけ共有する
- ポリシーに反したアクセスを防ぐためにパスワードの共有を禁止する
といったポリシー遵守は、組織の人数に比例して難しくなるので技術的施策が必要となってきます。
そうした対策としてパスワードマネージャーを採用している企業も少なくないかと思います。
グッドパッチではパスワードマネージャーとして1Passwordを採用してますが、SCIMサーバーの構築はしていないこともあり1Password上でのアクセス権および管理権限の運用遵守が悩ましいポイントでした。
SWAとは
Secure Web Authentication（SWA）とは、SAMLやWS-Fedのような連携プロトコルをサポートしないWebアプリケーションにSSO機能を提供するOktaの機能です。
少し噛み砕いて伝えるとIDとパスワード認証しかないサービスでもOktaを使うことができるよ。というものです。
SWAを採用してよかったこと
メンバーにパスワードを知らせることなくログインを可能にする
SWAには以下のようにログイン方式を選択できます。
今回は共有アカウントを利用するので、 Users share a single username and password set by administrator を選択します。
この方式を選択することで、メンバーはログインする際にパスワードを意識することなくサービスにログインができるようになります。
メンバーからすればOktaと連携している他のサービスと同様の体験で利用ができるようになります。
管理者からすればパスワードを知られることがないのでチャットツールで共有してしまうといったことがなくなります。
ロールベースアクセス制御（RBAC）に基づいたアクセス権の管理が容易になる
RBACとは、ユーザーの役割に基づいてアクセス権や権限を制御するというものです。 www.okta.com
OktaではUniversal Directoryを用いることでRBACに基づいてサービスへのアクセス権の制御ができるようになります。 例えば、HRメンバーにだけAというサービスを付与する。正社員ならBというサービスを付与するがインターンメンバーには付与しないといったことが可能です。
共有アカウントをSWAで管理することでアクセス権の制御をOktaに移譲することができるので負荷の少ない運用ができます。 また、曖昧になりがちな共有アカウントを誰が使ってよいかかが言語化されるためポリシーの解像度も上がることが期待できます。
サービスごとに管理権限を移譲できる
役割によって自動化しても例外としてサービスへのアクセス権を付与したい場合があります。
そうした場合は、 Application Manager をメンバーに渡して管理権限を移譲することも検討できます。
複数の共有アカウントの管理権限を移譲しても管理側の体験が一緒なので学習コストが比較的少なくて済みます。
SWAを採用して今後に期待したいこと
多要素認証を管理できない
残念ながらOktaのSWAは多要素認証に対応していません。そのため、多要素認証を設定できるサービスはOktaの配下におけません。
例えば当社ではクラウドサインを採用しているので、本当はOktaでアクセス権を管理したいのですが二要素認証に対応していないので 1Passwordを使っています
パスワードマネージャーとの棲み分けが片手落ちに
グッドパッチでは1Passwordを採用しており個人およびチームでのパスワード管理は1Password、組織での管理はOktaとしています。
ただ、多要素認証に対応していないので、後者の管理が一部1Passwordになるので片手落ち感があります。
グッドパッチではまだ1PasswordのSCIMを採用できていないので、今後SCIMを利用してGroupsの管理をしっかりできるようになればSWAを廃止して1Passwordに統一も検討できるかもしれません。 こちらは今後検討したいと考えています。
SWAを構築する上で便利だったもの
Chrome EnterpriseでOktaのChrome Extentionを配布する
SWAを利用するにはChrome Extentionの利用が必須のためメンバーにインストールをしてもらう必要があります。
Chrome Enterpriseを利用するとChrome Extentionを自動で配布ができます。
グッドパッチではJamf ProでChrome Enterpriseを配布しているので、漏れなくOktaのChrome Extentionを配布することを実現しています。
Jamf Proを用いたChrome Enterpriseの配布については rotomxさんの以下記事がわかりやすかったです。 note.com
余談ですがChrome EnterpriseはChromeの自動更新も強制できるのでおすすめです。
Templateを用いてOINのカタログにないサービスにも対応する
OIN(Okta Integration Network)に対応していないサービスも Template を利用すれば対応できます。
SWAは、次へボタンを押してからパスワードを入力するといったサービスによってログインの手順が違うものでも柔軟に対応できます。
Templateの作成については hagi さんの記事が詳しく検証されており、とても参考になりました。
何でもかんでもOktaから入れるようにしてみた | DevelopersIO
むすび
OktaのSWAを用いることで、管理と体験をOktaに一元化できることができるようになります。
導入自体がそんなに敷居が高くないので手軽に利用ができるのも良いポイントだと感じました。
一方で多要素認証に対応しておらず、パスワードマネージャーとの棲み分けについては今後も検証して最適解を探したいと思います。
そして一緒に検証をして、グッドパッチの認証基盤をより使いやすく強固にしていけるメンバーを探しています！
カジュアル面談大歓迎です！ 気軽にお声がけください。
また、Goodpatchではデザイン好きなエンジニアの仲間を募集しています。 少しでもご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
