このページは Cloud Translation API によって翻訳されました。

Apigee CMEK のベストプラクティス

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

リスクの防止

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

アクセス制御を強化する: roles/cloudkms.admin ロールまたは鍵の破棄/更新権限を、信頼できる管理者または上級チームメンバーにのみ制限します。
権限を定期的に監査する: 権限が時間の経過とともに誤って拡張されないようにします。
鍵の自動削除: 鍵を自動的に削除または無効にする自動化は設定しないでください。

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

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

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

鍵のローテーションの主な目的は、古い鍵バージョンを完全に置き換えることではなく、単一の鍵で暗号化されるデータの量を減らすことです。ランタイム鍵とコントロールプレーン鍵の両方で、元の鍵バージョンは作成された瞬間からリソースに関連付けられたままになります。

わかりやすい例

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

現在の制限: 自動再暗号化なし

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

キーの無効化

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

鍵（または鍵バージョン）の不正使用が疑われる場合:

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

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

ランタイム CMEK の侵害: 新しい CMEK を使用して新しいインスタンスを作成し、トラフィックが移行されたら元のインスタンスと古いランタイム CMEK を削除します。
すべての CMEK が侵害されている場合: 新しい CMEK 鍵を使用して新しい apigee 組織を作成し、構成を複製してトラフィックをシフトしてから、古い組織をシャットダウンし、元の CMEK を無効または削除します。
Google Cloud カスタマーケアにお問い合わせください。インスタンスまたは apigee 組織の削除/再作成の API に非常に時間がかかる場合は、Google Cloud カスタマーケアにお問い合わせください。

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

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

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

鍵の再有効化

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

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

鍵を削除する

キーを削除する前に、次の点を検討してください。

クリーンアップ目的の場合: Apigee が鍵の追跡をリリースして鍵の使用状況を把握するまで、古い鍵を削除しないでください。
削除が必要な場合: まず鍵を無効にしてから、破棄をスケジュールします。組織のポリシーを使用して、まず鍵を無効にし、破棄までの最小期間を設定できます。

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

顧客管理の暗号鍵（CMEK）が侵害された場合は、侵害された鍵を無効化、取り消し、破棄するための即時対応が重要です。ただし、この必要なセキュリティ対策により、Apigee システムが機能しなくなり、ダウンタイムやサービスの中断につながる可能性があります。

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

CI/CD と IaC の力

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

使用可能なツール

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

Apigee インスタンスのみを再作成する場合は、ダウンタイムなしでの Apigee インスタンスの再作成をご覧ください。
Terraform を使用する場合は、オープンソースの apigee/terraform modules からアイデアを借用することを検討してください。
Apigee 組織を再作成する場合は、apigeecli、apigeecli organizations export、apigeecli organizations import を使用してバックアップの基盤として使用できます。組織のエクスポートと再作成をご覧ください。
上記のリストにないリソースをバックアップして復元する場合は、API を直接操作するか、別の apigeecli コマンドを使用する必要があります。

ベストプラクティス

定期バックアップ: 定期バックアップをスケジュールして、最新の構成を利用できるようにします。組織のエクスポートと再作成をご覧ください。
安全なストレージ: 暗号化されたリポジトリなどの安全な場所にバックアップを保存します。
復元をテストする: 復元プロセスを定期的にテストして、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 コマンドは、インスタンス、envGroup、EnvAttachments、エンドポイントアタッチメントを自動的に作成したり、プロキシをデプロイしたりしません。これらのリソースは管理できますが、import コマンドで直接管理することはできません。
この import コマンドは、ポータルサイトを自動的に作成しません。ポータルサイトの作成は、管理画面で手動で行う必要があります。
キーの削除に対する障害復旧に投資し、復元プロセスを定期的にテストして、新しく作成された 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

インポート後の手順

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

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

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

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

他の構成のバックアップと復元

他の構成のバックアップと復元には、次のいずれかを使用します。

IAM ルールの場合: gcloud projects get-iam-policy と gcloud projects set-iam-policy を使用して独自の IAM ポリシーをコピーし、プロジェクトと apigee 組織名を調整して、新しい Google Cloud プロジェクトと apigee 組織に適用できます。
他の Apigee 構成の場合: Apigee Management API を使用できます。

プロキシをデプロイする

次のいずれかを使用してプロキシをデプロイします。

apigeecli を使用する
Apigee コミュニティスクリプトをリファレンスとして使用します。
Apigee 管理 API を使用する。

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

トラフィックを切り替える手順は次のとおりです。

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

Apigee CMEK のベスト プラクティス