Slack ：Slackアプリの自動承認をやってみた
この記事はcorp-engr 情シスSlack（コーポレートエンジニア x 情シス）#1 Advent Calendar 2023の25日目の記事です。
はじめに
こんにちは
SaaS と Slack 連携するときにIncoming Webhookを使用することは珍しくないと思います。
で、このようなSaaSですと、ユーザーごとにIncoming Webhookを作成してほしいのように、全体の運用を考えてくれないのかって言いたくなるSaaSってあったりします。まぁ現所属企業の場合、そのSaaSに関して、情報システム部門は選定に関与もお金払ってないから良いのですが。。。。
この手のやり方ですと、ユーザー数が増えるごとに、ユーザーのタイミングでIncoming-webhookが増え、都度都度承認する工数が割りと管理者に取って負担になるのですよね。。。
そこで、Incoming-webhookのみのアプリに関しては、自動で承認、それ以外は管理者にてリスク判断を行うことで、エンドユーザーは条件を満たす場合、承認依頼を出したらすぐに利用開始できますし、管理者も判断工数や判断ミスの削減が期待できるので、Win-Winになります。
合わせて、それを可視化できれば尚良しです。
大まかな作業の流れ
スコープの評価をカテゴリーに分ける
オートメーションルールを作成する
評価順序を整える
手順
スコープの評価をカテゴリーに分ける
Slack App Directory のページから[管理]をクリックします
スコープのリスク判定を行うため、[スコープの評価] - [等級]のカラムを確認します。
[Incomming-webhook] - [等級] を [低リスク] に設定します。
オートメーションルールを作成する
[リクエスト] - [オートメーションルール] - [ルールの作成] を選択します。
ルール名などは第三者が判断できるものにするとして
[リクエストされたスコープ] - [は次のリスト内のみ] - [低リスク] を選択します。
解決を以下に設定します[承認のみ]を選択します。
通知先の結果ですが、オープンチャンネルを設定したほうが後々楽なので、[特定のチャンネル]を選択し、指定のチャンネルを入れます
この解決における追加情報は入れるとユーザーとのコミュニケーション量が減るのでわかりやすい文言をいれます。
このような形になります
今回は、評価順序はこのままで問題ありません
この状態で、Incomming-webhook のみのSlackアプリを作成すると自動承認となります。
実際にやってみた感想
だいぶ楽になりました。
Slackの管理者をやっていた方だとわかると思うのですが、こういった承認依頼は管理者側での対応は携帯でポチポチだから、見た目の工数は少ないかもしれません。
しかし、たまに結構強い権限でのスコープをぶっこまれて承認依頼が来たりするため、Slackアプリの承認行為は管理者で確認する精神的負担も多いです。
しかし、ユーザー側は急いで対応してほしいと言われることも多いので、Slackアプリの承認依頼が来るたびに若干憂鬱でした。
今は大多数のIncomming-webhookのみのスコープは自動承認にして、それ以外のものはヤバめなので慎重に判断できるようになりました。
終わりに
如何でしたでしょうか？
私は、管理者がやるべきことは判断することであり、自動化できることについてはできるだけ自動化し、率先してDX化をすすめべきだと思っています。
この内容がどこかの会社で活用され、Slack管理者の負担軽減になることを願って締めようと思います。
Discussion