見出し画像

【第483回】 Marketing Cloud のクライアントシークレットに有効期限が導入

Marketing Cloud Engagement では、2026 年 3 月から「API 認証」で使用するクライアントシークレットに 180 日間の有効期限が導入されています。

2026 年 3 月 25 日以降、一度もローテーションしていない既存のクライアントシークレットは、2026 年 9 月 30 日に期限切れとなります。

期限切れになると、そのクライアントシークレットを使用している API 連携の認証ができなくなるため、外部システムやスクリプトなどとの連携が停止する可能性があります。

そのため、まだ対応していない場合は、9 月までに対象となるインストール済みパッケージを確認し、必要に応じてクライアントシークレットをローテーションしてください。

重要:期限切れが迫っている通知メールを受け取ったユーザーの方自身が、対象の設定が何のために使用されているものなのか把握していないケースもあるでしょう。その場合は、過去に導入や設定を行ったベンダーへ確認することも検討してください。

この仕組みは 2026 年 3 月から新たに導入されたものであるため、それ以前に構築された環境では、ベンダー側も今回のクライアントシークレットの定期的なローテーションを前提とした実装を行っていない可能性が高いです。

メールによるリマインドの例
バナーで通知が出ている例

今回の変更を改めて整理

今回の変更で重要なのは、主に以下の点です。

1. クライアントシークレットの有効期限は 180 日

  • 新しく生成、またはローテーションしたクライアントシークレットには、生成日から 180 日間の有効期限(TTL:Time-To-Live)が設定されます。

  • 180 日を過ぎると、そのクライアントシークレットは自動的に失効します。

  • つまり、今回だけ対応すればよいわけではありません。

  • 今後も継続して、クライアントシークレットのローテーションが必要になります。

2. 既存のクライアントシークレットは 2026 年 9 月 30 日に失効

  • 2026 年 3 月 25 日より前から使用しており、その後一度もローテーションしていないクライアントシークレットについては、2026 年 9 月 30 日が最初の期限となります。

  • 一方、2026 年 3 月 25 日以降にすでにローテーションしている場合は、9 月 30 日ではなく、新しいシークレットを生成した日から 180 日後が期限となります。

  • そのため、「すべてのパッケージが 9 月 30 日に期限切れになる」というわけではありません。

  • まずは、実際に設定されている有効期限を確認してください。


まずは自分の環境を確認

Marketing Cloud Engagement の以下の場所を開きます。

  • セットアップ > プラットフォームツール > アプリ > インストール済みパッケージ

インストール済みパッケージの一覧には、クライアントシークレットの 有効期限(Expiration Date)が表示されます。

ここで、2026 年 9 月 30 日 となっているパッケージがある場合は、今回の対応対象となります。

特に、以下のような環境では注意してください。

  • Salesforce パートナーなどが過去に API 連携を実装している

  • 外部システムと Marketing Cloud Engagement を API 連携している

  • CloudPages や Automation Studio の SSJS から API を実行している

  • Apps Script などの外部スクリプトから Marketing Cloud Engagement API を利用している

  • 過去に構築したシステムで、現在は構築ベンダーとの保守契約がない

クライアントシークレットだけを変更すると、それまで古いシークレットを利用していたシステムが認証できなくなります。

「シークレットを変更すること」よりも、「そのシークレットがどこで使われているのかを把握すること」の方が重要です。


クライアントシークレットローテーション手順

ローテーション自体は、既存の API 連携をすぐに停止させる仕組みではありません。

Marketing Cloud Engagement では「ステージングされたシークレット」を利用することで、既存のシークレットを維持したまま、新しいシークレットをテストできます。

そのため、基本的には次の流れで対応します。

まずは、セットアップ > プラットフォームツール > アプリ から「インストール済みパッケージ」に移動してください。


Step 1:新しいシークレットを生成

1. 対象となるインストール済みパッケージを開き、「ステージングされたシークレット」セクションから「生成」をクリックします。

2. 適切な「説明」を入力して、次へ進みます。

3. 新しいクライアントシークレットが生成 されます。

注意:ここで表示されたシークレットは必ず保存してください。

  • シークレットを確認できるのは、生成時のみです。

  • コピーし忘れた場合は再度生成する必要があります。

  • また、新しいシークレットは短時間に何度も生成することはできません。


Step 2:API 連携側のシークレットを変更

続いて、API 連携しているアプリケーションやシステム側で、古いクライアントシークレットを新しく生成したシークレットへ変更します。

例えば、以下のような場所です。

  • 外部アプリケーション

  • ミドルウェア

  • Apps Script

  • SSJS

  • CloudPages

  • Automation Studio の Script Activity

  • その他、Marketing Cloud Engagement API を利用しているプログラム

ここで重要なのが、まだ新しいシークレットを有効化しないことです。

ステージングされたシークレットを生成した状態では、既存のアクティブなシークレットと、新しく生成したステージングされたシークレットの両方を使用して認証できます。

そのため、既存の連携を止めることなく、新しいシークレットへ順番に切り替えてテストできます。


Step 3:新しいシークレットで動作確認

連携先のシークレットを書き換えたら、実際に API 認証や処理を実行して、問題なく動作することを確認します。

例えば Apps Script であれば、スクリプトを実行して正常にアクセストークンが取得できるか、その後の API 処理まで正常に完了するかを確認します。

Automation Studio の Script Activity などで使用している場合も、対象処理をテストして正常に完了することを確認してください。

新しいシークレットで正常に動作することを確認してから、次の「有効化」へ進みます。


Step 4:新しいシークレットを有効化

新しいシークレットを利用したすべての連携が正常に動作することを確認したら、ステージングされたシークレットを「有効化」します。

ここは非常に重要です。

ステージングされたシークレットを有効化すると、それまで使用していた古いシークレットは無効になります。

そのため、古いシークレットを使用している連携が残っている状態で有効化すると、その連携は動かなくなります。

必ず、関連する連携先をすべて新しいシークレットへ変更したことを確認してから有効化してください。


期限前の通知について

クライアントシークレットの期限が近づくと、「メール通知」に加えてMarketing Cloud Engagement 上にも「バナー通知」が表示されます

メール通知

バナー通知

そのため、有効期限には気付きやすい仕組みになっています。

ただし、通知だけに依存するのではなく、インストール済みパッケージの有効期限を管理し、定期的にローテーションする運用を決めておくことをおすすめします。


今後は 180 日ごとに対応が必要

今回の 2026 年 9 月 30 日を乗り切れば終わりではありません。

新しく生成したクライアントシークレットにも、生成日から 180 日間の有効期限が設定されます。

例えば 2026 年 9 月にローテーションした場合、次回の期限は、おおよそ 2027 年 3 月になります。

そのため、今後はインストール済みパッケージについて、

  • パッケージ名

  • クライアントシークレットの有効期限

  • そのパッケージを利用しているシステム

  • シークレットを設定している場所

  • 管理担当者

などを管理しておくことをおすすめします。

特に複数のシステムや SSJS、Apps Script などから利用している場合は、「半年後にどこを書き換えればよいのか分からない」状態を作らないことが重要です。


シークレットのハードコードにも注意

今回の変更を機に、クライアントシークレットの管理方法自体を見直すのもよいでしょう。

Salesforce も、サーバーや SSJS など、クライアントシークレットが使用されている場所を把握し、インストール済みパッケージ名や有効期限と合わせて管理することを推奨しています。

また、クライアントシークレットをコードへ直接ハードコードすると、認証情報の露出や、次回のローテーション時に更新箇所を見落とすリスクがあります。

外部アプリケーションであれば設定ファイルやシークレット管理サービス、SSJS など Marketing Cloud Engagement 内部で使用する場合も、可能な限り安全に管理できる仕組みを検討してください。


なぜこの変更が行われたのか?

Salesforce によると、公開されてしまった Marketing Cloud Engagement の API 認証情報を悪用し、

  • Marketing Cloud Engagement 環境への不正アクセス

  • フィッシングメールの送信

  • データの持ち出し

などを行う攻撃キャンペーンが確認されています。

今回の変更は、こうしたリスクから Marketing Cloud Engagement 環境を保護するための グローバルなセキュリティ強化策 です。

特定の Marketing Cloud Engagement 環境で発生したインシデントへの対応ではありません。


いかがでしたでしょうか。

まだ対応していない場合は、まず以下を確認してください。

  • インストール済みパッケージを確認する

  • Expiration Date が 2026 年 9 月 30 日になっているパッケージを確認する

  • API Integration が存在するパッケージの利用箇所を特定する

  • 新しいクライアントシークレットを生成する

  • 連携先を新しいシークレットへ変更する

  • 新しいシークレットで正常に動作することを確認する

  • 最後に新しいシークレットを有効化する

特に重要なのは、いきなりシークレットを有効化しないことです。

ステージングされたシークレットを利用して、既存のシークレットを残した状態で連携先を変更・テストし、問題がないことを確認してから有効化してください。

また、今回からクライアントシークレットには 180 日間の有効期限が設定されるため、今後は定期的なローテーションが必要になります。

2026 年 9 月 30 日は最初の大きな期限にすぎません。

これを機会に、「どのインストール済みパッケージを、どのシステムが利用しているのか」まで含めて管理できるようにしておくと、次回以降のローテーションもかなり楽になると思います。

今回は以上です。


次の記事はこちら

前回の記事はこちら

私の note のトップページはこちら