これは予防的なガイダンスです。引き続き調査を進めており、さらなる更新情報を共有する予定です。ワークスペースで想定外のキャンペーン、メッセージ、または API アクティビティに気付いた場合は、直ちに MoEngage のサポートおよびセキュリティチーム ([email protected]) にお問い合わせください。
適用されるローテーション方法
MoEngage では、キーをローテーションする方法が 2 つあります。再生成では、キーがその場で置き換えられ、古いキーは直ちに機能しなくなります。新しいキーの作成では、古いキーを廃止する前に移行できるため、ダウンタイムが発生しません。
インテグレーションがどのキーを使用しているかわからない場合は、MoEngage API を呼び出している各サーバー、スケジュールされたジョブ、サードパーティツール、ベンダーを確認し、最初の列の API と照合してください。
始める前に
- 各キーを使用しているすべてのシステム (バックエンドサービス、スケジュールされたジョブ、CI/CD 変数、データパイプライン、パートナーおよびベンダーのツール、保存済みの Postman コレクション) を一覧にします。
- Workspace ID を手元に用意しておきます。キーをローテーションしても Workspace ID は変わりません。
- 新しいキーは、ソースコード、チケット、チャット、メールではなく、シークレットマネージャーまたは暗号化された設定に保存します。
- 再生成するキーについては、短い変更時間枠をスケジュールし、設定の更新をデプロイできるよう準備しておきます。再生成した時点で、古いキーを使用した呼び出しは失敗します。
- Settings > Account > API keys を開けることを確認します。開けない場合は、ワークスペースの管理者に依頼してください。
Push API キーと Campaigns API V1 キーを再生成する
- MoEngage ダッシュボードで、Settings > Account > API keys に移動します。以前のページが表示されるワークスペースでは、Settings > Account > APIs に移動します。
- ローテーションするキーを見つけます。Push API は Push キーを使用します。Campaigns API V1、Business Events、Custom Templates、Catalog API は Campaign report / Business events / Custom templates / Catalog API キーを使用します。レガシーキーは、認証タイプ Basic Auth (Legacy) と表示されます。
- キーのアクションメニューを開き、Regenerate key を選択します。以前のページでは、代わりにキーの横にある Regenerate アイコンを選択します。
- 操作を確定します。
- 新しいキーをすぐにコピーし、シークレットマネージャーに保存します。
- 始める前にで一覧にしたすべてのシステムでキーを更新し、デプロイします。
- Push API の場合は、Push API リファレンスの説明に従って、新しいキーを使用して
X-MOE-PushAPI-Signatureヘッダーを再計算します。X-MOE-APPKEYヘッダーには引き続き Workspace ID を指定します。 - 各 API にテストリクエストを送信し、成功レスポンスが返されることを確認します。
401レスポンスは、リクエストがまだ古いキーを使用していることを意味します。
サポートされている API の新しいキーを作成する
以下の API グループでは、新しいキーを作成できます。この方法では、インテグレーションを新しいキーに移行している間も既存のキーが機能し続けるため、ダウンタイムは発生しません。Create new key が表示されない場合は、アカウントで有効にするよう MoEngage サポートに依頼してください。
- Settings > Account > API keys に移動し、+ Create new key を選択します。
- 最大 100 文字の一意の Key name を入力します。アーカイブされたキーは名前を保持するため、名前を再利用することはできません。
- Authentication type を選択します。キーの作成後は変更できません。
- Basic Auth: サーバー間呼び出し用の API キーとシークレットです。
- OAuth 2.0: 有効期限が 5 ～ 60 分 (デフォルトは 15 分) の短期間有効なアクセストークンです。盗まれたトークンはすぐに機能しなくなります。
- AWS STS Auth: 指定した AWS の引き受けロール ARN (キーごとに最大 10 個) のみを認可します。ワークロードがすでに AWS IAM ロールで実行されている場合に使用します。
- Select APIs for access で、そのインテグレーションに必要な API グループと個々の API のみを選択します。
- Create key を選択し、キーをコピーして安全に保存します。
- 新しいキーをインテグレーションにデプロイし、リクエストが成功することを確認します。
- API Keys ページに戻り、古いキーのアクションメニューを開いて Archive key を選択します。
アーカイブされたキーはアーカイブ解除できません。また、MoEngage はアーカイブ済みリストに最大 10 個のアーカイブ済みキーを保持します。古いキーは、すべてのインテグレーションが移行した後にのみアーカイブしてください。レガシーキーはアーカイブできないため、Push API キーと Campaigns API V1 キーを再生成するの手順でローテーションしてください。
API Firewall で IP による保護を追加する
キーをローテーションすることで、漏洩したキーが悪用可能な期間を制限できます。API Firewall は 2 つ目の制御を追加します。有効なキーを使用していても、許可リストにない IP アドレスからのリクエストには403 レスポンスが返されます。
Settings > Account > Security に API firewall タブが表示されない場合は、ワークスペースで API Firewall を有効にするよう MoEngage サポートに依頼してください。
Firewall の対象範囲
ルールは、Data、Segmentation、Campaigns、Partner Integration、Content の 5 つの API カテゴリに適用されます。すべてのルールは少なくとも 1 つのカテゴリを対象にする必要があります。適用はカテゴリ単位で行われるため、ルールを公開しても、保護されるのはそのルールが対象とするカテゴリのみです。ルールの設定と公開
Firewall ルールを追加するには、MoEngage ワークスペースの Admin である必要があります。まず、DevOps チームまたはセキュリティチームから、サーバーで使用されている静的 IP アドレスと CIDR ブロックの完全なリストを入手してください。
- Settings > Account > Security に移動し、API firewall タブを開きます。
- Enable API Firewall を選択します。
- わかりやすい Rule name (例: “AWS production servers”) を入力します。
- Whitelist categories で、ルールが対象とするすべてのカテゴリを選択します。
- Condition (単一の IPv4、単一の IPv6、IPv4 CIDR 範囲、IPv6 CIDR 範囲、または IPv4 範囲) を選択し、Value を入力します。
- Add rule を選択します。新しいルールは Unpublished として保存され、まだ適用されません。
- ステージング、バッチジョブ、MoEngage を呼び出すベンダーシステムを含め、すべてのサーバー IP について繰り返します。
- すべてのルールを選択して Publish を選択し、確定します。適用は約 15 分以内に開始されます。
Firewall を通過するようにパートナー連携を許可する
MoEngage API を呼び出すのは自社のサーバーだけではありません。一部のパートナー連携は、パートナーのインフラストラクチャから MoEngage に直接リクエストを送信するため、Firewall はそれらを他の呼び出し元と同様に扱います。カテゴリのルールを公開する前に、使用しているパートナーについて次の表を確認してください。パートナーがそのカテゴリで IP ホワイトリスト登録を必要とする場合は、パートナーの IP 範囲を取得してルールに追加してください。追加しない場合、MoEngage はパートナーのリクエストを403 レスポンスで拒否します。
Connected Segments (旧称 Outbound Segment Sync)、Streams、または Connector Campaigns を使用して MoEngage ワークスペースにデータを送信する場合は、MoEngage の IP アドレスをそのワークスペースのルールに追加してください。IP アドレスの一覧については、MoEngage の IP ホワイトリストを参照してください。
Firewall のヒント
- ルールで指定できるのは IP アドレスと CIDR 範囲のみです。ワイルドカードとドメイン名はサポートされていません。
- ルールは編集、公開取り消し、削除ができます。編集したルールは、再度公開するまで Unpublished に戻ります。
- Firewall で内部障害が発生した場合は、正当なトラフィックが引き続き流れるようにフェイルオープンします。
- ルールの変更は、変更ごとのユーザー、時刻、IP アドレスとともに Audit Logs に記録されます。
検証と監視
- すべてのインテグレーションが新しいキーで成功レスポンスを返し、古いキーを送信しているものが残っていないことを確認します。
- Audit Logs を確認して、各キーを誰がいつ作成、再生成、またはアーカイブしたかを確認します。
- Wiki、チケット、チャットメッセージ、コードリポジトリから、古いキーの保存済みコピーを削除します。
- 定期的なスケジュールで、またキーにアクセスできる人がチームやベンダーから離れるたびに、ローテーションを繰り返します。
FAQ
キーをローテーションすると Workspace ID は変わりますか？
キーをローテーションすると Workspace ID は変わりますか？
いいえ。変わるのはキーのみです。
再生成後に古いキーと新しいキーを併用できますか？
再生成後に古いキーと新しいキーを併用できますか？
いいえ。再生成すると、古いキーは直ちに無効になります。古いキーと新しいキーを並行して使用するには、サポートされている API の新しいキーを作成するの説明に従って新しいキーを作成してください。
アーカイブしたキーを復元できますか？
アーカイブしたキーを復元できますか？
いいえ。アーカイブされたキーはアーカイブ解除できません。代わりに新しいキーを作成してください。
すでにキーをローテーションした場合でも Firewall を使用すべきですか？
すでにキーをローテーションした場合でも Firewall を使用すべきですか？
はい。この 2 つの制御は異なるリスクから保護します。ローテーションは漏洩した可能性のある認証情報を置き換え、Firewall は後から有効なキーが漏洩した場合でも、不明な IP アドレスからのリクエストをブロックします。
サポートが必要な場合は誰に連絡すればよいですか？
サポートが必要な場合は誰に連絡すればよいですか？
カスタマーサクセスマネージャーに連絡するか、ダッシュボードから MoEngage サポートにチケットを作成してください。