お久しぶりです。1年振りにテックブログを書くことになりました、hacomonoで情シスを務めている遠藤です。
ちょうど1年前に「hacomonoのIT環境がここ半年で180度変わった話」というタイトルでテックブログを書かせて頂きましたが、今回はその続きとなります。
あれから…
2022年6月当時100人だった正社員は右肩上がりで増え、今や200人を超える正社員数となりました。
それに伴い、入退社・異動・その他諸々の対応についてOktaで自動化を進めてきましたので、今回はこの1年間Oktaでやってきたことを紹介していければと思います。
SmartHRの部署情報との連動
前回のテックブログ以降、hacomonoでは従業員DBを持つことが出来るSmartHRを導入しました。
入社体験の向上、組織図の可視化、人事評価のシステム運用等々、他に実現した事は多くありますが、情シス観点としてはOktaとのSCIM連携が実現したことが導入の大きな決め手になりました。
SmartHRの導入に合わせてOktaのGroupを見直し、これまで部署単位でしか作っていなかったGroupをチーム単位や雇用形態×部署まで細分化しました。
Groupの振り分けはSmartHR→OktaへのSCIM連携でDepartmentには所属チームが、User typeには雇用形態が流れてくるので、その情報を利用して振り分けRuleを作成しています。
//Group Ruleの一例 【IF】 ( user.department=="経理" OR user.department=="総務" OR user.department=="法務" OR user.department=="コーポレート" OR user.department=="Corporate" ) AND ( user.userType=="正社員" OR user.userType=="役員" ) 【THEN】 Assign to "People & Culture_コーポレート(正社員)
これによりSmartHRで部署情報が変更される=付与される権限やアプリケーションも変わる。という状態を作り上げることが出来ました。
OktaとSCIMで繋がっているSaaS
Google Workspace & Slack
Google WorkspaceのMLやSlackのグループメンションは部署やチームと連動していることが多く、これまでは入社日に情シスが1人1人手動で各グループに追加していました。
しかし、SmartHR→Oktaの連携が出来てからはSmartHR→Okta→Google Workspace or Slackという形で情シスの手を介在すること無く連動させることが出来るようになりました。
1Password
hacomonoではパスワードマネージャーに1Passwordを採用しており、部署に応じて利用できるVaultsが割り当てられています。
1Passwordに関してもこれまでは入社時に1人1人1PasswordのGroupを割り当てていましたが、前述のGoogle Workspace,Slackと同様に自動でGroupを割り当てるようにしました。
SmartHR→Okta→ 各SaaSへの連携図は↓のようになります。
Device Trust
これまでフリーダムだったSaaSへのアクセスをOkta×MDM(Jamf Pro/Intune)によってDevice Trustな状態を作り上げることが出来ました。
具体的には、これまで私用デバイスでも会社のConfidentialな情報や個人情報を多く含むSaaSにアクセス出来ている状態でしたが、コンプライアンスの観点から機微な情報は会社から貸与したデバイスからのみアクセス出来るよう制限しました。
設定はクラウドネイティブさんのブログが分かりやすいです。
Okta側での制御としてはAuthenticator Policy
でDevice Trust専用のRuleを作成しており、Deviceの状態がRegistered(Oktaに登録済み)
かつManaged(証明書適用済)
な状態の場合のみ、機密性の高いアプリケーションにアクセス可能としています。
この証明書はOktaから発行されMDMを経由して配布することにより、MDM配下のデバイス(=会社から貸与デバイス)のみ特定のアプリケーションにアクセスすることが可能となります。
試しにDevice Trustのポリシーが適用されているアプリケーションに私用デバイスから入ろうとすると、下記のように権限が無いと表示されます。
hacomonoの管理サイトとの連動
これまでhacomonoへhacomonoの従業員がログインする際には、1Passwordに保存されている環境ごとの認証情報を利用していました。
ただ、この認証情報が全従業員共通であること、必要のない従業員まで過剰な権限を与えていることが前々から社内外で懸念事項とされていました。
今回、外部からの指摘もあり以下の対応を取ることになりました。
- 1Passwordでhacomonoの認証情報を保持することを廃止
- 今後顧客環境へのログインはOktaを利用
- 顧客環境へのログイン権限は事前申請制
- 権限はsu権限と通常権限の2つに分かれており、チームに応じて
su権限・通常権限・権限無し
と分かれる
- 権限はsu権限と通常権限の2つに分かれており、チームに応じて
今回の対応はhacomono側及びOkta側(+申請ワークフロー)の対応が必要となり、私はOkta + 申請ワークフローの対応を構築しました。
hacomono側の対応はいつか”まっつん”がテックブログで書いてくれるはずです🙄
ワークフローからOktaへの連携方法としては、ワークフロー(kickflow)で「CTOが承認→OktaのUser Profileを変更→hacomonoにログインする権限を付与」という流れを構築。というような流れになります。
OktaのUser Profileの編集やGroupのAssignはOkta Workflowsを利用しました。
kickflowで申請した内容が承認されるとWebhookを経由してOkta Workflowsに流れ込み、申請内容に応じてGroupの付与、User Profileの編集を実施しています。
この対応により、顧客環境に対する不要なログインを防ぐことが出来ただけでなく、過剰な権限によるオペレーションミスの防止、情報漏洩の防止(通常権限は個人情報がマスクされる)、Oktaを利用した認証の強化を実現することが出来ました。
最後に
1年前はただのSSOツールとして利用されていたOktaですが、あれから1年経ちEX(従業員満足度)の向上や会社や従業員を守ることが出来るレベルまで構築が進みました。
hacomonoは1年前から従業員が倍に増え、それに伴い新しいお客様とのお付き合いも増えたことで、hacomonoの社会的責任の大きさをひしひしと感じております。 その責任を感じながらこれからもhacomonoの情シス一同、業務に邁進していきたいと思います。
少々長くなりましたが、お付き合い頂きましてありがとうございました。
Oktaはいいぞ!!!!!
株式会社hacomonoでは一緒に働く仲間を募集しています!
採用情報や採用ウィッシュリストも是非ご覧ください!