こんにちは！たつみんです！
弊社ではIdPとしてOktaを利用しつつも、パスワードマネージャーとしてKeeperを利用しています。
Keeperで保管する認証情報として個人がベンダーのサポートサイトのID,PasswordをKeeperに保管している場合もあれば、個人に紐づかないアカウントの認証情報、例えばOkta緊急アクセス用アカウントのID,PasswordをKeeperの共有フォルダに保管している場合もあります。
今回、Okta緊急アクセス用アカウントと同様の要件を持つアカウントの合計2アカウントの利用状況についてKeeper監査ログで後から確認するのではなく、利用時にすぐに確認できるようにOkta WorkflowsでSlackに通知する仕組みを実装しました。
これにより相互監視の意識が働き不正の抑止効果が期待できます。
弊社では通常OKta FastPassを活用し、パスワードレスを実現しています。しかし、Okta緊急アクセス用アカウントの認証情報であるパスワードをKeeperで管理しアラートを発生させるという特性上、パスワードレスの仕組みは好ましくありません。そのため、Authentication Policyではこのアカウント専用のルールを追加し、Password + Another factorとすることで必ずPasswordの利用が必要となるに調整しました。
前提条件
Keeper
アラート機能を利用するにはBusiness PlusもしくはEnterprise Plusであることが必要です。
Okta Workflows
1 Flow作成可能であることが必要です。
どんな通知がされるか？
今回のOkta Workflowsでは以下のような通知がされます。
設定方法
今回はKeeperの共有フォルダに保管された2個の記録について、以下の5個のイベントが発生した場合に通知を実施します。()内は後述のWebhook設定をした際にaudit_eventの値として含まれる内容です。
- 記録が開かれました(open_event)
- 記録が入力されました(fast_fill)
- アップデートした記録(record_update)
- 記録が削除されました(record_remove)
- 記録共有が変更されました(change_share)
なお、今回2個の記録でそれぞれ通知先のSlackチャンネルを分けるという要件もありますがKeeper上のアラート設定は1個とし、通知先の制御はOkta Workflows側で行います。
Keeper記録のUIDの確認
まずは以下の方法で通知を行いたい記録のUIDを調べます。
- ユーザーとしてKeeperを開き通知を行いたい記録を開き、オプションから記録の情報をクリックします。
- 表示されたUID部分をクリックします。
以下のスクリーンショットではwucGAZ1QUOZTbYcC2mix7A部分がUIDです。
なお、今回Okta Workflowsで処理するうもうひとつの記録のUIDはzbRRzVd5kgaQ36YrSuEqVQとします。
Okta Workflows設定
今回作成するFlowの全体像は以下となります。
If/ElseIfカード内の分岐処理5,6,7および9,10,11,12については後述いたします。
- トリガーにはAPI Endpointカードを選択し、Security levelをSecure with client tokenとしました。(カード解説)
Aliasが反映された状態のInvoke URLとClient tokenは後ほどKeeper管理画面でアラート設定時に必要となります。 - Get Multipleカードで1.で受け取った
bodyの中から必要な情報を取り出します。（カード解説） - Date To Textカードで、2.で取り出したtimestampのタイムゾーンをJSTに変換し、同時にフォーマットをYYYY-MM-DD形式とします。（カード解説）
- If/ElseIfカードで2.で取り出したrecord_uidが
wucGAZ1QUOZTbYcC2mix7Aの場合とzbRRzVd5kgaQ36YrSuEqVQの場合をそれぞれ指定します。（カード解説）
outputをオブジェクト型とし、キーとしてKeeper Display name,mention,Slack Channel IDを指定しておきます。 - record_uidが
wucGAZ1QUOZTbYcC2mix7Aの場合に、ConstructカードでキーとしてKeeper Display name,mention,Slack Channel IDを作成し、値を直接設定します。outputを4.のIf/ElseIfカードのoutputとして指定します。（カード解説）
なお、このmentionで指定している値<!subteam^S03MXLAPMJ4>はSlackユーザーグループの場合の指定の方法となります。
- 5.と同様にrecord_uidが
zbRRzVd5kgaQ36YrSuEqVQの場合に、ConstructカードでキーとしてKeeper Display name,mention,Slack Channel IDを作成し、値を直接設定します。outputを4.のIf/ElseIfカードのoutputとして指定します。（カード解説）
こちらのmentionで指定している値<@U02RWB02PEV>はSlackユーザーの場合の指定の方法となります。
- Elseの場合にConstructカードでキーとして
Keeper Display name,mention,Slack Channel IDを作成し、値としてKeeper Display nameに対しては2.のrecord_uidを指定し、他の項目は直接指定します。outputを4.のIf/ElseIfカードのoutputとして指定します。（カード解説）
補足：ここではrecord_uidが想定した2パターン以外が発生した時でも処理を継続できるように設定をしています。
- If/ElseIfカードで2.で取り出したaudit_eventがそれぞれのパターンごとに指定します。outputをテキスト型とします。（カード解説）
- audit_eventが
open_event,fast_fill,record_update,record_removeの場合は以下のようにComposeカードそれぞれに応じたメッセージを作成し、outputを7.のIf/ElseIfカードのoutputとして指定します。（カード解説）
audit_event毎に文言を認証情報を開きました。や認証情報を自動入力しました。のようにしています。
- audit_eventがchange_shareの場合はGet Multipleカードで1.で受け取った
bodyの中からto_usernameを取り出します。（カード解説） - 9.で取り出した
to_username含めてComposeカードでメッセージを作成し、outputを7.のIf/ElseIfカードのoutputとして指定します。（カード解説）
- Elseの場合に以下のようにComposeカードでaudit_eventをそのまま引用したメッセージを作成し、outputを7.のIf/ElseIfカードのoutputとして指定します。（カード解説）
補足：ここではaudit_eventが想定した5パターン以外が発生した時でも処理を継続できるように設定をしています。
- SlackアプリケーションのSend Message to ChannelカードでChannel IDに4.のoutputから
Slack Channel IDを指定し、Textには7.のoutputを指定します。この時オプションでSlack botとして送信することを指定しているためBotの名前やアイコンを指定しておきます。（カード解説）
Keeper管理画面でのアラート設定
次にKeeperのアラート設定を行います。
- Keeper管理画面からレポートとアラートへ移動し、アラートタブをクリックします。
- アラートの追加からアラート条件でイベントタイプをクリックし、検索から先述した5個のイベントを検索しチェックを入れます。
- 属性をクリックし、UID記録を選択し事前に確認したUIDを入力し、追加をクリックします。この操作を繰り返して通知を行いたいUIDを追加します。今回は合計2個のUIDを追加しています。
- 受取人を追加をクリックし、受取人名にわかりやすい名称を作成します。
- 追加Webhookをクリックし、URLにOkta Workflowsの手順1.で生成したInvoke URLを入力します。同じようにトークンにOkta Workflowsの手順1.で生成したClient tokenを入力し、保存をクリックします。
動作確認
実際にKeeperで対象の記録を開いたり、ブラウザ拡張機能での自動入力を行いaudit_eventを発生させ正しく通知がされるかを確認します。
動作確認段階ではOkta Workflows設定の5.6.7.でのメンション部分や通知先のSlackチャンネルはテスト用としておくとよいでしょう。本番相当のメンションや通知先を利用する場合は事前にテスト通知が発生することをアナウンスしておきましょう。
KeeperのSlack Webhooksと比べて
実はKeeperには以下のようにSlack Webhooksという仕組みがありOkta Workflowsを使わずとも通知を行うことが可能です。
このKeeprのSlack WebhooksとOkta Workflwosと比べるとそれぞれ以下のようなメリットデメリットがあると思います。
KeeperのSlack Webhooksのメリット
- 上記のKeeperのドキュメントを参考に比較的容易に構築可能
- Slackアプリを作成すればKeeper側の設定のみで実現可能
KeeperのSlack Webhooksのデメリット
- 通知先チャンネル毎にWebhook URLを発行する必要があるため、Keeperアラート設定も個別に設定する必要がある
- Alert NameやUIDがそのまま出力されるため通知内容が直感的ではない
Okta Workflwosのメリット
- Slackへの通知内容のカスタマイズが容易
- アラート設定と通知処理を分割することが可能なため、Keeperのアラート設定を一つにまとめることが可能
- Slack通知以外の他SaaS連携を行うことも可能
Okta Workflowsのデメリット
- 1 Flowを消化するため、Flow作成可能数に余裕がない時は特に注意が必要
- 柔軟さがある分、Okta Workflowsに慣れていない場合は構築が難しい場合がある
まとめ
弊社で運用しているKeeperとSlack通知についてご紹介しました。実は今回、KeeperのSlack Webhooksを検討する前に個人的にOkta Workflowsでの実装に手が慣れていたのですぐにFlowを作成していましたが、改めて比べてみるとOkta Workflowsの柔軟さが際立つ結果となりました。
Okta Workflowsは自由度が高く触れているとさまざまなアイディアが浮かんでくるとても好きな製品です。Okta Workflowsについて活発なやり取りがある海外コミュニティをチェックしているとFlowを作成する人のこと指す言葉としてFlowgrammerという造語があるようです。
この記事がFlowgrammerの役に立てば幸いです。
