WorkdayとOktaを連携してアカウント管理運用を省力化した話
この記事は Eureka Advent Calendar 2021 15日目の記事です。
こんにちは。エウレカの恩田です。
今回の記事では、エウレカにおける人事台帳とIdentity Provider(Okta)の統合によるアカウント管理の進化の歩みについて紹介します。
アカウント管理は戦いの基本にして奥義
アカウント管理、皆様ちゃんとできてますか？(震え声)
この記事でお話するアカウント管理とは、会社の社員が業務で利用してる各種Webサービス/ツールのユーザアカウントを管理する業務を指しています。
わかりやすい例だと、Google Workspace、AWS、Slack、Microsoft Office365、Githubなどなど。バックオフィス関連でいえば人事労務管理システム、経費精算システム、契約書管理システムなどでしょうか。プロダクト開発チームではタスク管理ツール、デザインマネジメントツール、システムパフォーマンス計測ツール、カスタマーケア部門であればカスタマーサービスプラットフォームなどが上げられます。ともかく現代の職場にはあらゆるWebサービスが業務で利用されています。
また、会社の業務プロセスというのは組織の成長と共に肥大化していくのが世の常です。様々な職能チームが生まれ、様々な業務プロセスが会社で生まれると共に、それを支えるツール群は増えていきます。
エウレカではアカウント管理業務を情報システム部門が行っています。しかし、中央集権的にアカウント管理を行うには管理成熟度を高めていかなければ会社全体の業務ボトルネックとなりますし、未成熟なアカウント管理体制はセキュリティホールの温床となるため、アカウント管理体制の強化が急務でした。
理想的なアカウント管理とギャップ調査
そこで、アカウント管理における理想像の策定と現状把握、そして課題の整理を行いました。まずは、どんな状態でありたいのかの言語化を行いまいました。結果、以下のようにまとめられました。
理想像
- 従業員が業務利用してるツールを把握できている
- ツール毎に、どんな情報が存在するのかを把握できている
- 従業員は入社後速やかに業務上必要なツールに必要な権限でアクセスできる
- 従業員の異動、退職時は速やかにアカウントの権限変更および凍結が行われる
- ツール毎のユーザリストと権限、およびパスワードポリシー等の設定構成が正確に把握できており、それらが全社で定められたセキュリティポリシーに従い(乖離することなく)、最小権限の原則やパスワードポリシーなどが実装できている
- 個人情報など機密性の高い情報を管理するツールは、権限変更が特定いち個人で完結できないよう然るべき承認プロセスが存在し、権限昇格をバイパスができないようになっている。
- アカウント利用状況に異常が見られた場合、速やかに検知、一時凍結等の措置を取る事ができる
こんな事できていて当たり前！言われればそれまでですが、この状態を少人数で実現、管理運用するのは並大抵の事ではありません。
適切なアカウント管理およびポリシーの実装はセキュリティ要件と密接に関わるため、ツール郡を正確に把握しており、かつどんなデータがどこに保管されてるのを知っていて初めて適切なコントロールが可能となります。
また、従業員に負担を強いる業務システム(利用開始に時間がかかる、可用性が低い、利用したい機能が使えない、都度依頼が必要、待ち時間が長いなど) は組織内シャドーITを生みだす土壌となりセキュリティ上好ましくありませんし、なにより業務生産性観点で望ましくありません。
次に、現状のアカウント管理業務の整理と課題を集約しました。結果、以下のような課題に集約されることがわかりました。
課題
- 従業員台帳管理部門とアカウント管理部門は管掌が別、かつ連携がスムーズに取れておらず、従業員毎の速やかなアカウントの作成/凍結/権限付与/変更/剥奪ができていない。
- サインインポリシーがツール毎にバラバラかつ棚卸しができていない & 棚卸しコストが高い
- 可監査性が低く、セキュリティ構成不備やログイン試行異常等に気づきづらい
- アカウント管理業務に情報システム部門の時間が大きく取られている
ゴール設定
次に、定めた理想形に近づくためのアクションプランを定めました。
- 従業員はまずOktaにログインをし、Okta経由で各種業務アプリにSingle Sign Onしてツールを利用するのを標準とする。また、OktaでSingle Sign On可能な業務アプリのカバー率を100%に近づける。
- 従業員が利用可能なアプリと権限は、人事台帳に登録された従業員属性を基点とし自動で決定されるようにする。また権限付与/変更/凍結は人事台帳に登録された入退社日時や情報変更日時を元に自動で行われるようにする。
- Okta上でSign On PolicyとRBAC(Role Base Access Control)の一元中央管理を行い、サインインポリシーや従業員リスト、権限一覧の棚卸しコストを下げつつ、サインインポリシーを標準化する。
次に、これらを実現するための具体的な実装を進めました。
1. 人事台帳とOktaの連携
エウレカでは人事管理システムとしてWorkdayを利用しています。従業員の入退社や所属変更などが発生したら、人事部がWorkdayに従業員情報を登録 / 更新します。
OktaとWorkdayをインテグレーションすることで、Workdayに登録されてる人事情報をOktaに同期することができます。
取り組みの第一歩として、Workdayに登録された入社日時を基点に自動でOktaアカウントが生成され、かつその従業員属性情報がOkta側に同期される仕組みに切り替えました。
2. 従業員の属性に応じたOkta Groupへの自動アサイン
次に、アプリへの権限付与をグループ単位で管理するために、Okta上でのユーザグループと所属ルールを整理しました。
OktaにはGroup Ruleという仕組みがあり、従業員の属性に応じて特定のOkta Groupに自動で所属させることができます。
例えば、Workdayに登録されている従業員の所属部門名がAの場合、Okta Group [a,b,c]に自動で所属させる、といった事が可能です。(正規表現でルールを書く事もできる)
既存Groupの整理とGroup Ruleを整理し、Oktaにアカウントが作られた従業員は自動で予め定められたGroupに自動で所属するよう整理を行いました。
3. 業務アプリとOktaの連携・GroupとAppsのマッピング
次に、Okta経由でSingle Sign Onさせるアプリの登録と設定を行います。Oktaでは、主に以下3つの設定を行います。
- Sign On Policy Setting
- Provisioning Setting
- Assignment (Group or Individual)
Sign On Settingは、Oktaとアプリを連携し、Okta経由でアプリにSingle Sign Onを実現するための設定です。SAMLやOpenID Connect (OIDC)といったインテグレーションを選択、利用できるので、アプリ毎に設定していきます。
次に、Provisioning Settingです。Okta経由でSingle Sign Onさせる先のアプリに対し、Provisioning / Deprovisioning設定をすることで、Okta上のユーザの状態に応じて自動でアプリ側のアカウント作成、削除などができるようになります(＊アプリによってどこまでProvisioning Settingがサポートされてるかは異なります)
最後にアプリに対してOkta Groupのマッピングをします。
例えば、業務アプリAにGroup a,b,cを紐付けます。すると、Group a,b,cに所属する従業員はアプリAをOktaのApp Catalogから見つけることができ、そこからSingle Sign Onが可能になります。
まだまだ業務アプリ全部をOktaに連携できてるわけではありませんが、連携済業務アプリを少しずつ拡充しつつ、同時にアプリ毎にどのGroupがSign In可能かマッピングを整理していきました。
4. Okta Group毎のSign On Policyを設定
ここまでで、各アプリへログインはOktaにログインすれば以後OktaのApp Catalogから選択 > Single Sign Onできるようになりました。
次に、Okta自体へのSign Onポリシーです。Oktaにログインできる =その人に割り当てられているアプリにログインできる、という事なので、Oktaログインに用いる認証情報が外部に漏れた場合、アプリへのSign inも突破されてしまいます。そのため、Okta本体のSign On Policyの強度と妥当性が非常に重要になります。
Oktaでは、所属するOkta Group毎にSign On Policyを設定できます。Sign On Policyは以下3つの構成要素で成り立っています。
- Sign On Rule
- MFA
- Password Policy
Sign On Ruleはユーザの行動特性に基づく認証の可否や、多要素認証を求める頻度等を司ります。行動特性とは、具体的には、IPアドレス、デバイス、地理情報、ログイン試行のvelocityなどです。
Sign On Ruleに従属するリソースとして、OktaではBehavior Detecionというリソースを作成し、それをSign On Ruleとマッピングすることで実装します。
(例：Rule作成画面)
これらを活用し、強権限を持つOkta Groupに所属する従業員に対しては、普段と異なるIPアドレスからのログイン時は常に多要素認証を求める、といった実装が可能です。
(Behavior Detectionの例)
MFAポリシーはどのグループに対しどの多要素認証手段(i.e：SMS、Okta Verify、Google Authenticator)を許可 & 強制するかを司ります。
すごく細かく制御したい場合を除き、これは一律全従業員にMFA強制 & 認証手段はOkta Verify(ないしは特定の認証要素を1つ) を適用しておけばよいでしょう。
最後にPassword Policyです。これはパスワード長やComplexity、ローテーション間隔やLogin Attemp Failer時のロックアウト挙動、パスワードを忘れた際のセルフリカバリ等の可否の設定を司ります。
特に細かい制御が必要ないのであれば、グループ別にポリシーを分ける必要もないので、一律で十分な強度を設定したポリシーを設定するのがよいと思います。
これらをOkta Group毎に適切な粒度で設定してやることで、セキュリティ強度と利便性の両立を実現することができます。
従業員全体に適用されるSign On RuleとMFAおよびPassword Policyを見直しつつ、特権管理者をはじめ機密情報にアクセスするOkta GroupのSign On Ruleの整備を行いました。
5. Oktaの構成管理をTerraformで行う(＊未達)
エウレカではPairsのインフラ構成管理にTerraformを利用しています。
TerraformはOkta Providerもサポートしており、これまで説明してきたOktaの構成管理をIaCとして管理する事が可能です。
変更履歴はOktaの管理ログで追えるとはいえ、変更管理体制においてレビュープロセスがあることが望ましいので、構成変更管理をIaCに寄せる事で可監査性も向上させることができます。
また、Githubのブランチ保護設定を有効化し、マージ前に必ずGithub上で特定チーム / 担当上長等の承認が必須となるよう仕込みをしておけばベターです。
＊ ただし、Okta連携したアプリのConfigurationをすべてTerraformで管理するのは結構大変なので、Applicationの構成(SAML連携等) はOktaのGUIから行いTerraform側ではDataSourceとして参照。ApplicationとGroupのマッピングやGroup Rule、Sign On PolicyのみIaCで管理する、といった割り切りをしてもよいと思います。
現時点ではまだ調査と既存構成のimportを少し始めた程度で、まだまだ全てをTerraform x Github Flowで管理する体制にはなっていませんが、徐々にシフトしていく予定です。
以下、TerraformでOktaの構成管理を行うサンプルコードです。(Group Ruleに基づきユーザをGroupにアサイン & 特定のアプリと紐付ける)
# tfstate Backend(S3)
terraform {
required_version = ">= 1.0.0"
backend "s3" {
bucket = "hoge"
region = "ap-northeast-1"
key = "okta/terraform.tfstate"
encrypt = true
}
required_providers {
okta = {
source = "okta/okta"
}
}
}
# Configure the Okta Provider
provider "okta" {
org_name = "your org name"
base_url = "okta.com"
}# App Definition (datasource)
data "okta_app" "app_1" {
label = "app"
}# Group Definition
resource "okta_group" "test_terraform" {
name = "terraform group test v1"
description = "test group created via terraform"
}# Add Group Rule
resource "okta_group_rule" "test_1" {
name = "test terraform 1"
status = "ACTIVE"
group_assignments = [
"okta_group.test_terraform.id"
]
expression_type = "urn:okta:expression:1.0"
expression_value = "String.startsWith(user.firstName,\"takuya\")"
remove_assigned_users = false
}# App x Group Assignment
resource "okta_app_group_assignments" "test_terraform" {
app_id = "data.okta_app.app_1.id"
group {
id = "okta_group.test_terraform.id"
priority = 1
}
}
まだまだ戦いは続く
ここまで、エウレカ情報システム部門がアカウント管理をシュッとするために行ってきた取り組みを紹介しました。
しかし、まだまだ道半ば、というのが正直な感想です。特に、業務アプリ全体のうち、OktaでSingle Sign OnおよびProvisioningをカバーできているアプリの割合はまだ100%には程遠い状態で、Oktaを使い倒すには、まだまだ人も時間も足りてないのが現状です。
何が言いたいかというと、現在エウレカ情報システム部門は絶賛採用募集中ですので、ご興味ある方はぜひご応募いただけると嬉しいです。
