Slack では、セキュリティを大変重視しています。チームのデータが安全に保護されることは重要です。これには、Slack の API を使ったアクセスや、皆さんがチームのために作成するアプリも含まれます。
Slack では、アプリのセキュリティ機能を向上し続けています。この記事では、皆さんのアプリをどのように保護すべきかを説明します。
トークンを特定の IP 範囲に制限する
既存のコードを変更せずにアプリを保護する最も簡単な方法は、アプリのトークンに対する IP アドレスの制限 です。この機能を有効にすると、Slack は、アプリの設定で指定された IP アドレスからの Web API へのリクエストのみを受け入れます。
リクエストが指定した IP 範囲と一致する場合、Slack は通常と同じように処理を行います。この範囲外の IP からトークンを使用するリクエストを受信した場合、Slack は invalid_auth エラーを返します。
IP を有効にするには、api.slack.com/apps からアプリ管理機能にアクセスします。OAuth & Permissions 機能をクリックすると、Restrict API Token Usage というセクションが表示されます。CIDR 表記を使って、最大 10 個の IP 範囲を、範囲または個別のアドレスとして指定できます。指定した IP 範囲は保存後すぐに有効になり、アプリを再インストールする必要はありません。
この機能は、内部アプリ (つまり、公開配信のリストに記載されていないアプリ) のみで利用でき、アプリから Slack の Web API メソッド への呼び出しに使用できます。
リクエスト署名
Slack API では、リクエストが本当に Slack からのものかをアプリで確認するために、リクエスト署名を使用することもできます。これは、アプリ固有の共有シークレットを使用して、Slack が送信するすべてのリクエストを検証するという方法です。リクエスト署名は、Slack がアプリにデータを送信する API メソッドでサポートされています。これには、スラッシュコマンド、Events API リクエスト、インタラクティブ・メッセージ、アクション、メッセージボタン、メッセージメニュー、レガシー Outgoing Webhook が含まれます。
Slack がアプリに送信するすべてのリクエストには、X-Slack-Signature HTTP ヘッダーが含まれています。このヘッダーには、HMAC-SHA256 キー付きハッシュが設定されています。このハッシュは、アプリ固有のシークレットをキーとして使って計算されます。この共有シークレットは、アプリの管理ページの Basic Information セクション、Signing Secret の項目にあります。
署名を検証するには、バージョン番号 (現在は常に v0)、X-Slack-Request-Timestamp HTTP ヘッダーの値、リクエスト自体のメッセージ本文の順で、コロン (:) で区切って連結し、基本文字列を作成します。例えば、基本文字列は次のようになります: v0:1538352000:token=abc123def456xyz....
この基本文字列とアプリの共有署名シークレットをキーとして使用し、SHA256 ハッシュを計算します。計算結果として得られるハッシュは、X-Slack-Signature ヘッダーの値と一致するはずです。一致しない場合、アプリはリクエストを破棄してください。
ハッシュは、タイムスタンプとリクエスト・ボディの両方を使用して計算されるので、Slack とアプリ間での通信中にリクエストそのものが改ざんされていないことを確認できます。必要に応じて、共有シークレットはアプリの管理ページから直接再生成できます。
リクエストの検証に静的 Verification token（検証トークン）を使用してきたという人もいるかもしれませんが、現在この方法は推奨されていません。将来的にはサポートされなくなる予定です。リクエスト署名はより安全です。共有シークレットが各リクエストと一緒に送信されることはなく、リクエストの内容が転送中に改ざんされていないことを検証でき、中間攻撃者からも保護されます。リクエスト署名は Node.js と Python の Slack 公式 SDK にも含まれており、しっかりサポートされています。
リクエスト署名を使用したリクエストの検証 の詳細なステップを説明したガイドもご覧ください。
相互 TLS による 2 要素認証
リクエスト署名は、アプリケーションコードの変更を最小限に抑えてアプリを保護する直接的な方法です。別の方法として、TLS サーバーによる暗号化された署名証明書を使用して認証を処理することもできます。TLS とリクエスト署名のどちらでも、リクエストが Slack から発信され、メッセージの内容が改ざんされていないことを検証できます。しかし、相互 TLS は、リクエスト自体のハッシュの計算ではなく、証明書による検証を行います。検証をどの時点で行うかは、皆さんが自由に決めることができます。
相互 TLS では、TLS Termination サーバーを構成し、リクエストをアプリケーションに送信する前にカスタムヘッダーを挿入できなければなりません。その後、アプリケーションはヘッダーの値をチェックして、リクエストが実際に Slack から発信されたことを確認します。アプリでの 相互 TLS の使用 に関する推奨手順についてもご覧ください。
ご質問やご意見については、devsupport@slack.com 宛てにメールでお問い合わせいただくか、@SlackAPI にツイートしてください。どんなアプリができるでしょうか？楽しみにしています！
原文 Securing your Slack apps by Jim Ray