Apigee での CMEK に関するベスト プラクティス

このページでは、Apigee での CMEK に関するベスト プラクティスについて説明します。

リスクの防止

現在 Apigee は、顧客管理の暗号鍵（CMEK）の機能を制限付きでサポートしています。CMEK または特定の鍵バージョンの誤削除を防ぐため、次の対策を実施することをおすすめします。

  • アクセス制御を強化する: roles/cloudkms.admin ロールまたは鍵の破棄 / 更新権限を、信頼できる管理者または上級チームメンバーのみに付与します。
  • 権限を定期的に監査する: 権限を持つユーザーの範囲が時間とともに意図せずに拡大していないことを確認します。
  • 鍵の自動削除: 鍵の自動的な削除 / 無効化は設定しないでください。

鍵の破棄期間とローテーションを設定する

  • デフォルトの破棄期間の延長を検討する: デフォルトでは、スケジュールした破棄が実行されるまでの期間は 30 日間です。鍵の作成時にカスタムの破棄期間を設定するか、組織のポリシーによってより長い期間を適用することで、誤って削除した鍵を復元できる期間を延長できます。破棄期間が長くなるとリスクが高まるように思える場合は、鍵を誤って削除せずに済むというメリットにも注意してください。メリットとリスクのバランスを取って、最適な期間を判断できます。
  • 破棄の前に鍵の無効化を要求する: 鍵バージョンの破棄をスケジュールする前に、鍵バージョンを無効にすることをおすすめします。これは、鍵がアクティブに使用されていないことの検証に役立つため、鍵バージョンを破棄しても安全かどうかを判断するうえで重要なステップです。
  • 鍵のローテーションを実装する: 鍵を定期的にローテーションすることで、鍵の漏洩によって生じる影響を制限できます。鍵が漏洩した場合、定期的なローテーションを行っていれば、実際に不正使用されるメッセージの数が制限されます。

Apigee での鍵のローテーション

鍵のローテーションの主な目的は、古い鍵バージョンを完全に置き換えることではなく、1 つの鍵で暗号化されるデータの量を減らすことです。ランタイム鍵とコントロール プレーン鍵のどちらの場合も、リソースの作成時に関連付けられた鍵バージョンが、ずっとリソースに関連付けられています。

例

  • Apigee インスタンスは、作成時に有効だったプライマリ CMEK の鍵バージョンを、鍵のローテーション後もずっと使用します。
  • プロキシ バンドルは、最初の作成時に有効だったプライマリ CMEK の鍵バージョンをずっと使用します。ただし、プロキシ バンドルが鍵のローテーション後に変更された場合、その中の新規データは新しいプライマリ鍵のバージョンで暗号化されます。

現在の制限: 自動的な再暗号化はありません

重要な点として、Apigee は現時点で、鍵のローテーション時における既存データの自動再暗号化をサポートしていません。限られた量の新規データだけが、新しいプライマリ鍵バージョンで暗号化されます。分析情報、ランタイム ディスクデータ、古いプロキシ リビジョンなど、大部分のデータは引き続き古い鍵バージョンで暗号化されます。

キーの無効化

鍵を無効化または破棄すると、Apigee の機能が中断されます。鍵を無効にすれば、鍵の漏洩が誤検出だった場合に再度有効にできます。

鍵（または鍵バージョン）の漏洩が疑われる場合:

  • 高リスクのシナリオ: 関連する Apigee データの機密性が高く、攻撃者が悪用する可能性が高いと思われる場合は、すぐに鍵を無効にして鍵へのアクセス権を取り消します。apigee インスタンスと apigee 組織を再作成する前に、鍵を無効にする必要があります。
  • 低リスクのシナリオ: 潜在的なリスクよりもダウンタイムを最小限にとどめることが優先される場合は、CMEK を無効化または削除する前に、まず apigee インスタンスと apigee 組織を再作成する必要があります。バックアップと復元への投資によってダウンタイムを事前に防ぐ方法については、以下をご覧ください。
  • サポートに問い合わせる: 鍵の漏洩が確実で、無効にする必要があると思われる場合は、Google Cloud カスタマーケアにお問い合わせになることをおすすめします。

鍵の無効化、取り消し、破棄の影響については、こちらをご覧ください。鍵を無効にした後は、apigee 組織 / インスタンスを再作成する必要があります。ベスト プラクティスについては、こちらをご覧ください。

  • ランタイム CMEK の漏洩: 新しい CMEK を使用して新しいインスタンスを作成し、トラフィックが移行された後で元のインスタンスと古いランタイム CMEK を削除します。
  • すべての CMEK の漏洩: 新しい CMEK を使用して新しい apigee 組織を作成し、構成をレプリケーションしてトラフィックを切り替えた後、古い組織をシャットダウンして元の CMEK を無効化または削除します。
  • Google Cloud カスタマーケアに問い合わせる: インスタンスまたは apigee 組織の削除 / 再作成用の API に非常に時間がかかる場合は、Google Cloud カスタマーケアにお問い合わせください。

鍵の無効化、取り消し、破棄の影響

鍵を無効化、取り消し、破棄すると、Apigee が正常に機能しなくなります。影響は次のとおりです。

  • 鍵全体の無効化、取り消し、破棄: Apigee の顧客向け API が直ちに機能を停止します。数分以内に内部システムで障害が発生し、プロキシのデプロイ、ランタイム トラフィック、分析、API セキュリティに影響が出ます。ディスクの再マウントに関する問題により、インスタンスは数週間以内に完全に起動不能になります。
  • 鍵バージョン（プライマリ鍵バージョンまたは以前の鍵バージョン）の無効化、取り消し、破棄: その鍵バージョンを使用する Apigee の顧客向け API が直ちに機能を停止します。一部の内部システムとランタイム トラフィックが影響を受けます。その鍵バージョンがディスク暗号化に使用されていた場合は、インスタンスが起動不能になる可能性があります。

鍵の再有効化

鍵の漏洩が誤検出だった場合や、意図せずに鍵が無効化された場合は、無効になっている鍵を再度有効にできます。鍵を再度有効にすると、顧客向け API の機能が復元され、内部システムが数分以内に復旧するはずです。ただし、鍵が使用できなかった期間中に、API セキュリティと分析に関するデータ損失が生じていた可能性があります。

  • 鍵の無効化期間が短かった場合: API セキュリティと分析に関するデータ損失を除き、システムは復元されます。
  • 鍵の無効化期間が長かった場合: システムは復元してトラフィックの処理を再開しますが、1 つのリージョンから返される値と停止していたリージョンから返される値が違うといった、データの不整合が発生する可能性があります。Apigee クラスタを修正するには、Google Cloud カスタマーケアにお問い合わせください。

鍵の削除

鍵を削除する前に、次の点に注意してください。

CI / CD バックアップによる Apigee 組織の保護

顧客管理の暗号鍵（CMEK）が漏洩した場合は、その鍵の無効化、取り消し、破棄といった対応を直ちにとる必要があります。ただし、この必要なセキュリティ対応によって Apigee システムが機能しなくなり、ダウンタイムやサービスの中断につながる可能性があります。

Apigee サービスのダウンタイムをゼロまたは最小限に抑えるため、組織の構成の継続的なバックアップ（継続的インテグレーション / 継続的デプロイ（CI / CD）バックアップ）という事前対応型のアプローチを実装することが不可欠です。Apigee 組織の復元に使用できるツールとベスト プラクティスをご覧ください。

CI / CD と IaC のメリット

Infrastructure as Code（IaC）ソリューションである Terraform などのツールに投資すると、バックアップされた構成から新しい Apigee 組織をシームレスに作成することが可能になります。効率化されたプロセスによって Apigee 組織を迅速かつ効率的に再作成できるため、ダウンタイムを最小限に抑え、ビジネスの継続性を確保できます。

使用可能なツール

次のツールをすべて組み合わせることで、apigee 組織を定期的にバックアップし、復元プロセスをテストできます。

ベスト プラクティス

  • 定期的なバックアップ: 復元時にできるだけ新しい構成を使用できるよう、定期的なバックアップをスケジュールします。組織のエクスポートと再作成をご覧ください。
  • 安全なストレージ: 暗号化されたリポジトリなど、安全な場所にバックアップを保存します。
  • 復元のテスト: 復元プロセスを定期的にテストして、Apigee 組織を効果的に復元できることを確認します。また、新しく作成された Apigee 組織にトラフィックを迅速に切り替えられることも確認します。

組織のエクスポートと再作成

apigeecli ツールは、Apigee リソースの管理に使用できるコマンドライン ツールです。gcloud コマンドのように、使いやすいコマンドライン インターフェースで Apigee API と同じアクションを実行できます。
Apigee 組織を再作成する場合や、別の Apigee 組織に移行する場合は、apigeecli organizations export と apigeecli organizations import を使用できます。これは継続的なバックアップの基盤としても使用でき、次のようなリソースをエクスポートおよびインポートできます。

  • API ポータルのドキュメント
  • API ポータルのカテゴリ
  • API プロキシ
  • API セキュリティの構成とセキュリティ プロファイル
  • 共有フロー
  • API プロダクト
  • デベロッパー
  • デベロッパー アプリ（認証情報を含む）
  • AppGroup とアプリ（認証情報を含む）
  • 環境の詳細
  • 環境グループ
  • データコレクタの構成
  • 環境レベルのキーストアとエイリアス証明書
  • 環境レベルのターゲット サーバー
  • 環境レベルの参照
  • 組織 / 環境 / プロキシ レベルの Key-Value マップ（KVM）とエントリ
  • キーストアとエイリアス証明書（秘密鍵を除く）

このツールを使うと、他のすべての Apigee リソースも管理できます。apigeecli tree を使用して、コマンドの一覧を表示できます。

このツールにはいくつかの制限があります。

  • キーストアでは、秘密鍵を作成時に保存し、ローカル バックアップ ファイルに含める必要があります。
  • OAuth トークンをバックアップして復元することはできません。つまり、新しく作成された Apigee インスタンスでは再ログインが必要です。
  • 組織のポリシーや IAM ルールなどのアクセス制御は移行されません。このようなルールを移行するには Google Cloud API を使用する必要があります。
  • 分析レポートのエクスポートはサポートされておらず、分析の指標は新しい apigee 組織にコピーされません。
  • import コマンドの実行時に、インスタンス、環境グループ、環境アタッチメント、エンドポイント アタッチメントが自動的に作成されたり、プロキシが自動的にデプロイされたりすることはありません。これらのリソースは管理可能ですが、import コマンドで直接管理することはできません。
  • import コマンドの実行時に、ポータルサイトが自動的に作成されることはありません。ポータル サイトの作成は、UI を使って手動で行う必要があります。
  • 鍵の削除への対策として障害復旧に投資するとともに、復元プロセスを定期的にテストして、新しく作成された Apigee 組織にトラフィックを迅速に切り替えられることを確認することをおすすめします。

前提条件

開始する前に、次の前提条件を満たしていることを確認してください。

  • Apigee CLI がインストールされている: インストール ガイドの手順に沿って apigeecli をインストールします。
  • 認証: Apigee 組織を操作するために必要な権限と認証情報を用意する必要があります。以下の設定を完了してください。
    • Google Cloud SDK（gcloud）: インストールと認証を済ませておきます。
    • アクセス トークン: gcloud auth print-access-token を使用してアクセス トークンを取得します。
  • ネットワーク アクセス: ネットワークで Apigee API へのアクセスが許可されていることを確認します。
  • 組織の作成: 移行先の新しい apigee 組織を作成します。作成可能なさまざまなタイプの apigee 組織がありますが、元の組織と同じタイプ（従量課金制またはサブスクリプション）の組織と、同じタイプのネットワーク ルーティングを使用してください。

Apigee 組織のエクスポート

コマンドの例を以下に示します。さまざまなフラグの詳細については、apigeecli organizations export をご覧ください。

# Sample command
mkdir apigee_backup
cd apigee_backup

# gcloud auth application-default login
export ORG_FROM=REPLACE
apigeecli organizations export -o $ORG_FROM --default-token

Apigee 組織のインポート

コマンドの例を以下に示します。さまざまなフラグの詳細については、apigeecli organizations import をご覧ください。

# Sample command
# gcloud auth application-default login
export ORG_TO=REPLACE
apigeecli organizations import -o $ORG_TO -f . --default-token

インポート後の手順

インスタンスを作成してネットワークを設定する

インスタンスを作成してネットワークを設定する手順は次のとおりです。

  1. 新しいインスタンスを作成するの手順に沿って、新しいインスタンスを作成します。
  2. ノースバウンド トラフィックを構成する: ノースバウンドとは、外部または内部のクライアントからロードバランサを経由して Apigee に向かう API トラフィックを指します。インスタンスに到達できるように、PSC または VPC を適切に構成する必要があります。新しい組織で環境グループのホスト名を設定する必要があります。
  3. サウスバウンド トラフィックを構成する: サウスバウンドとは、Apigee から API プロキシ ターゲット サービスに向かう API トラフィックを指します。NAT 用に新しい IP アドレスを予約して有効にし、ターゲット エンドポイントでファイアウォール / 許可リストを再構成する必要があります。

詳細については、Apigee ネットワーキング オプションをご覧ください。

他の構成をバックアップして復元する

他の構成をバックアップして復元する場合は、次のいずれかの方法を使用します。

プロキシをデプロイする

次のいずれかの方法でプロキシをデプロイします。

トラフィックを切り替える

次の方法でトラフィックを切り替えます。

  1. 新しいインスタンスの自動化されたインテグレーション テストを準備します。
  2. パフォーマンスをモニタリングしながらトラフィックを新しいインスタンスに徐々に移行するように、ロードバランサを構成します。