ヘルプ CloudSpend GCP推奨事項
CloudSpendの推奨事項レポートで、クラウドリソースを調整し、コストの最適化とパフォーマンスの向上を行います。コスト、可用性、セキュリティ推奨事項チェックが下記GCPサービスでグループ分けされています。
GCPサービスのコスト推奨事項は次の通りです。
自動バックアップが有効になっている場合、リソースが最大容量に近づくと、ストレージ制限が (永続的に) 増加します。
設定の編集セクションのストレージ設定でストレージの自動増加が有効になっているかどうかを確認します。
CloudSQL インスタンスにラベルが適用されているかどうかを確認します。
ラベルは、Google Cloud リソースを整理するのに役立つ Key-Value ペアです。これらは、コンソールでのリソースのフィルタリング、請求の管理、リソース ポリシーの作成に使用できます。ラベルのない CloudSQL インスタンスは、大規模な環境では管理、追跡、コストの割り当てが難しい場合があります。
CloudSQL インスタンスに適切なラベルを適用して、リソースの組織化、コストの追跡、ガバナンスの機能を向上させます。環境、アプリケーション、部門、コストセンター、プロジェクトなどのラベルを使用して、Google Cloud リソース全体に一貫したラベル付け戦略を実装することを検討してください。
インスタンスのラベルが空かどうかを確認します。
GCP を使用すると、ユーザーはラベル (キーと値のペア) の形式でメタデータを割り当てて、インスタンスをより適切に追跡および管理できます。組織は、VM リソース ファームを効率的に管理するために、関連するラベル グループと実用的なラベル付け戦略を考案します。
GCP のベスト プラクティスに準拠したラベル付け戦略を作成します。
クラスタのラベルが空かどうかを確認します。
Google Cloud プロジェクトが複雑になるにつれて、ユーザー定義のラベルにより可視性と組織性が強化されます。 GKE クラスタに戦略的にラベルを付けると、管理が合理化され、本番、ステージング、開発などの検索やグループ関連サービスが簡素化され、効率的に制御できるようになります。
Google Cloud のベスト プラクティスに準拠したラベル付け戦略を作成します。
関数にユーザー定義のラベルがあるかどうかを確認します。
Cloud Run Functions にラベルを割り当てると、リソースの管理と整理が容易になります。ラベルは、コストの追跡、リソースのグループ化、ポリシーの適用に使用できます。
ラベルを作成して Cloud Run 関数に割り当て、リソース管理と組織を改善します。
サービスラベルが空かどうかを確認します。
GCPプロジェクトが複雑になるにつれて、ユーザー定義のラベルにより可視性と組織性が強化されます。戦略的に、クラウド実行サービスにラベルを付けると、管理が合理化され、検索が簡素化され、実稼働、ステージング、開発などの関連サービスがグループ化されて効率的に制御されます。
GCP のベスト プラクティスに準拠したラベル付け戦略を作成します。
GCP ストレージ バケットの無効になっているライフサイクル管理ポリシーを確認します。
ライフサイクル管理ポリシーは、オブジェクトを別のストレージ クラスに移行したり、一定期間後にオブジェクトを削除したりするなど、ストレージバケット内のオブジェクトのライフサイクルを管理するのに役立ちます。
ライフサイクル管理ポリシーを実装して、ストレージ コストを最適化し、オブジェクトのライフ サイクルを効果的に管理します。
Cloud Pub/Subトピックをチェックして、ユーザー定義のラベルのないトピックを特定します。
ラベルは、Pub/Subリソースの整理と分類に役立つキーと値のペアです。ラベルを使用すると、Google Cloud環境全体でリソース管理、コスト追跡、フィルタリング機能が向上します。
意味のあるラベルをPub/Subトピックに適用して、リソースの編成を改善し、管理を簡素化し、コスト配分を強化します。
マネージド ゾーンのラベルが空かどうかを確認します。
ラベルは Cloud DNS リソースの整理と分類に役立ち、コストの割り当てと運用のためのリソースのフィルタリング、追跡、管理が容易になります。
リソースの組織と管理に関する Google Cloudのベストプラクティスに従って、Cloud DNSマネージドゾーンにラベルを適用します。
GCPサービスの可用性推奨事項は次の通りです。
自動バックアップでは、Cloud SQL データベースの定期的なスケジュールされたバックアップを作成することで、貴重なデータを確実に保護します。偶発的なデータ損失、データベースの破損、またはその他の予期せぬ問題が発生した場合でも、データを以前の状態に簡単に復元できます。
「バックアップ」セクションで、自動バックアップが有効になっているかどうかを確認します。
ZONAL の可用性を構成したインスタンスを確認します。
Google Cloud SQL で高可用性 (HA) 構成またはデータベース クラスタを有効にすることで、計画的なメンテナンスや停止中にデータの冗長性が維持されます。指定された Google Cloudリージョン内のプライマリ ゾーンとセカンダリ ゾーンの両方で動作するため、高可用性向けに構成された Cloud SQLインスタンスはリージョンインスタンスと呼ばれます。
すべての本番環境およびミッションクリティカルな Google Cloud SQLデータベースインスタンスにHAと自動フェイルオーバーのサポートが設定されていることを確認してください。
ポイントインタイムリカバリフラグが設定されていないインスタンスをチェックします。
ポイントインタイムリカバリ (PITR) を使用すると、Google Cloud MySQLデータベースインスタンスを正確な瞬間、さらには正確な秒まで復元できます。この機能は、エラーによってデータ損失が発生した場合、またはデータベースが破損した場合に特に役立ち、データベースを問題が発生する前の動作状態に戻すことができます。
GCPアカウント内のすべてのMySQLデータベースインスタンスに対してポイントインタイムリカバリ (PITR) 機能が有効になっていることを確認します。これにより、コスト効率を維持しながら、特定の時点からデータを復元できます。PITRを有効にする前に、MySQLデータベースインスタンスに対して自動バックアップとバイナリ ロギングの両方が有効になっていることを確認してください。
MySQLインスタンスに対してslow_query_log フラグが有効になっているかどうかを確認します。
slow_query_logフラグは、定義された実行時間を超えるクエリのログを有効にします。これは、データベース内のパフォーマンスの問題と潜在的な最適化の機会を特定するのに役立ちます。
CloudSQL MySQL インスタンスでslow_query_log フラグを有効にして、パフォーマンスの遅いクエリを特定して最適化します。
PostgreSQLインスタンスのlog_error_verbosityフラグが冗長に設定されているかどうかを確認します。
log_error_verbosityフラグは、ログに記録されるメッセージの詳細レベルを制御します。詳細設定には、関数名、行番号、効果的なデバッグやトラブルシューティングに重要なその他の詳細が含まれます。
CloudSQL PostgreSQL インスタンスで log_error_verbosity フラグを冗長に設定して、包括的なエラー情報がログに記録されるようにします。
PostgreSQLインスタンスに対してlog_planner_statsフラグが無効になっているかどうかを確認します。
log_planner_statsフラグは、クエリプランナーのパフォーマンス統計をログに記録します。これにより、運用環境で過剰なログ エントリが生成される可能性があります。この詳細レベルは通常、特定のデバッグまたは最適化セッション中にのみ必要になります。
本番環境のCloudSQL PostgreSQLインスタンスでlog_planner_stats フラグを無効にして、過剰なロギングと潜在的なパフォーマンスへの影響を防ぎます。
Google Compute Engine インスタンスのリソース使用率をチェックし、過去 48 時間の CPU 使用率が 2% 未満の場合は、十分に使用されていないというラベルを付けます。
Google Compute Engineの場合、インスタンスタイプと消費時間数に基づいて料金が請求されます。使用率が低いインスタンスを特定して停止することで、コストを削減できます。さらに、Site24x7のガイダンスレポートには、現在のマシンタイプも表示され、コスト削減を図るためにダウングレードできる希望のインスタンスタイプ (推奨マシンタイプ) が表示されます。
GCPコンピューティングのパフォーマンスカウンターをチェックし、使用率が高いと思われるインスタンスを特定します。
コンピュートインスタンスは、次の基準を満たす場合、過剰使用されているとみなされます。
インスタンスのサイズを変更するか、インスタンスを自動スケーリンググループに追加することを検討してください。
ホストメンテナンス中のインスタンスがTERMINATEとしてマークされているかどうかを確認します。
Google Cloud Compute Engine を使用すると、インフラストラクチャのメンテナンス中にダウンタイムなしでVMインスタンスを移行できます。VMが新しいハードウェアに確実に移動されるように、可用性ポリシーの [ホストメンテナンス時] オプションを [移行] に設定します。
VMインスタンスをライブマイグレーション用に構成して、VMインスタンスが確実に新しいホストに移動されるようにし、メンテナンス中のダウンタイムを防ぎます。
インスタンスのプリエンプティブルフラグが有効かどうかを確認します。
プリエンプティブルインスタンスは、Google Cloudでいつでも停止できる、コスト効率が高く、有効期間が短いVMです。中断可能なワークロード向けに設計されており、大幅なコスト削減を実現しますが、最大実行時間は 24 時間です。
インスタンスがプリエンプティブルでないことを確認するには、次の手順に従います。
<オル>インスタンスのautomaticRestartフラグが有効かどうかを確認します。
Google Cloud Compute Engineサービスは、メンテナンスイベント、ハードウェアの問題、ソフトウェア障害など、ユーザーが開始したもの以外の理由により停止する場合があります。
停止されたインスタンスが許容日数を超えて存在しているかどうかを確認します。
インスタンスが停止している場合でも、ストレージに対して料金が発生する可能性があります。ただし、終了すると、すべての料金が免除されます。さらに、インスタンスが指定された期間実行されなかった場合、インスタンスはアクティブに維持されない可能性があるため、高いリスクが生じる可能性があります。
指定された期間後に停止したインスタンスがないことを確認してください。
関連するインスタンス ID について Compute Engine のディスク構成を確認します。
Compute Engine ディスクは、インスタンスの終了後、またはインスタンスからボリュームを明示的にアンマウントして接続解除した後でも、独立して存続できます。ご存知のとおり、接続されていないボリュームは、プロビジョニングされたストレージと 1 秒あたりの入出力操作 (IOPS) に基づいて引き続き課金されます。
構成済みの Compute Engine ディスクをアクティブなインスタンスに関連付けるか、ディスクを削除します。
クラスタノードの自動修復プロパティが無効になっているかどうかを確認します。
自動修復は、GKEクラスタノードの健全性を維持するのに役立ちます。有効にすると、GKEは各ノードの健全性を定期的にチェックし、ノードが設定された期間内に複数のヘルスチェックに失敗した場合、GKEは自動的に修復プロセスを開始します。
すべてのGKEクラスタノードの自動修復機能を有効にして、正常性を維持し、スムーズな動作を確保します。
ファイルストアのアクセス制御がIPアドレスまたは範囲に制限されているかどうかを確認します。
デフォルトでは、ファイルストアは同じプロジェクトおよびVPCネットワーク内のクライアントに無制限のアクセスを許可します。これにより、データ侵害が発生する可能性があります。セキュリティを強化するには、IPベースのアクセス制御を実装して、信頼できるIPアドレスへのアクセスを制限し、その他すべてをブロックします。
機密データへの不正アクセスを防ぐために、信頼できるIPアドレスまたは範囲を必ず確立してください。
関数のCMEKが設定されているかどうかを確認します。
Google Cloud は、Googleが管理する鍵を使用して保存されたデータを自動的に暗号化します。さらに制御するには、安全な鍵管理、ローテーション、取り消しのために Cloud KMS経由でCMEKを使用することを検討してください。
制御とコンプライアンスを強化するには、Googleが管理する暗号鍵の代わりにCMEKを使用します。
関数が最小インスタンス設定に構成されているかどうかを確認します。
Cloud Run機能ではコールド スタートが発生し、レイテンシが増加する可能性があります。これを最小限に抑えるには、関数インスタンスの最小数を設定します。これにより、一部のインスタンスがウォーム状態で準備完了状態に保たれ、レイテンシーが短縮されるため、応答時間が短縮され、信頼性が向上します。これは、一貫したトラフィックまたは低レイテンシのニーズがある本番ワークロードにとって重要です。
Cloud Run機能に十分なウォームインスタンスを設定することで、コールドスタート時間を短縮し、パフォーマンスを向上させます。
Cloud Runサービスに対してエンドツーエンドHTTP/2が無効になっているかどうかを確認します。
エンドツーエンドHTTP/2を有効にすると、リクエストの多重化が可能になり、レイテンシーが短縮されるため、パフォーマンスが向上します。これにより、Cloud Runで実行されるアプリケーションのユーザーエクスペリエンスが向上します。
Cloud RunサービスのエンドツーエンドHTTP/2を有効にして、パフォーマンスを向上させ、レイテンシーを短縮します。
Cloud Runサービスに最小インスタンス数が構成されているかどうかを確認します。
インスタンスの最小数を構成すると、Cloud Runサービスを常に利用できるようになり、トラフィックの突然の急増に対処できるようになります。
可用性を確保し、トラフィックの急増に効果的に対処するには、Cloud Runサービスのインスタンスの最小数を設定します。
GCPストレージバケットのバージョニング設定が有効になっているかどうかを確認します。
バージョニングを有効にすると、オブジェクトの複数のバージョンが保持されるため、誤った削除や上書きを防ぐことができます。
ストレージ バケットのバージョニングを有効にして、データ損失を防ぎ、オブジェクト履歴を維持します。
Cloud Pub/Subサブスクリプションをチェックして、デッドレターポリシーが設定されていないサブスクリプションを特定します。
デッドレターポリシーは、繰り返し試行しても処理できないメッセージを処理するメカニズムを提供します。デッドレターポリシーがないと、問題のあるメッセージによって処理がブロックされ、サブスクリプション内の他のメッセージの配信遅延が発生する可能性があります。
Pub/Subサブスクリプションのデッドレターポリシーを構成して、適切なメッセージ処理を確保し、処理できないメッセージによるサービス中断の発生を防ぎます。
インスタンス グループの自動修復設定が無効になっているかどうかを確認します。
自動修復は、異常なVMを自動的に修復することで、マネージドインスタンスグループの健全性と可用性を維持するのに役立ちます。有効にすると、Google Cloudは各インスタンスの健全性を定期的にチェックし、ヘルスチェックに失敗したインスタンスを再作成して、アプリケーションの可用性と復元力を確保します。
マネージド インスタンス グループの自動修復を有効にして、アプリケーションの信頼性を高め、インスタンス障害時の手動介入を減らします。
インスタンスグループが単一ゾーンにデプロイされているかどうかを確認します。
単一ゾーンのインスタンスグループはゾーン固有の停止に対して脆弱であり、アプリケーションの可用性に影響を与える可能性があります。リージョン (マルチゾーン) マネージドインスタンスグループは、リージョン内の複数のゾーンにVMインスタンスを分散し、ゾーン障害に対する可用性と復元力を高めます。
単一ゾーンマネージドインスタンスグループをリージョンマネージドインスタンス グループに変換して、アプリケーションの可用性を向上させ、ゾーンレベルの障害から保護します。
GCPサービスのセキュリティ推奨事項は次の通りです。
VMインスタンスの構成をチェックして、GCPコンソールで削除保護オプションが有効になっているかどうかを確認します。
インスタンスを誤って削除しないようにするには、GCPコンソールで削除保護オプションを有効にします。
削除保護オプションはデフォルトでは無効になっています。インスタンスが予期せず終了するのを防ぐには、このオプションを有効にします。
ネットワークインターフェイスの外部IPv4が割り当てられ、外部NATとして名前が付けられているかどうかを確認します。
Google Cloud Compute Engine インスタンスにパブリックIPアドレスを割り当てると、インスタンスが不要なセキュリティ リスクにさらされる可能性があります。
パブリックIPの代わりに、以下の代替アプローチのいずれかを使用することを検討してください。
インスタンスに接続されているディスクで autoDelete フラグが有効になっているかどうかを確認します。
デフォルトでは、Compute Engineインスタンスが削除されると、Google Cloudは永続ディスクを削除します。意図しないデータ損失が発生する可能性があります。
インスタンスのIP転送フラグが有効かどうかを確認します。
IP 転送により、VMは異なるネットワーク間でトラフィックをルーティングできます。有効にすると、VMはルーターのように動作して、あるネットワークから別のネットワークにパケットを転送できます。
インスタンスメタデータのシリアルポート有効キーがTrueに設定されているかどうかを確認します。
IP ベースのアクセス制御は、対話型シリアルコンソールではサポートされていません。これを有効にすると、IPアドレスに関係なく、正しいユーザー名、SSHキー、プロジェクトID、インスタンス名、ゾーンを持つ人は誰でも接続を試行できるようになります。
シリアルポート有効化キーをFalseに設定することで、明示的に無効にできます。
最新のデータベース機能を利用し、強化されたパフォーマンスとセキュリティの恩恵を受けるために、Google Cloud MySQL データベースインスタンスが MySQLデータベースの最新メジャーバージョンを使用していることを確認してください。
データベースのバージョンをアップグレードします。
最新のデータベース機能を利用し、強化されたパフォーマンスとセキュリティの恩恵を受けるために、Google Cloud PostgreSQL データベースインスタンスが PostgreSQLデータベースの最新メジャーバージョンを使用していることを確認してください。
データベースのバージョンをアップグレードします。
インスタンスのserverCaCertの有効期限が30日未満かどうかを確認します。
Cloud SQLデータベースインスタンスへのすべての受信接続に SSL/TLS プロトコルが必須の場合、アクセスは有効なSSL証明書を持つ認証されたクライアントに制限されます。有効期限が切れる前にSSL証明書を更新 (ローテーション) しないと証明書が無効になり、クライアントとデータベース インスタンス間の安全な通信が中断される可能性があります。
Cloud SQLデータベースインスタンスに構成されているすべてのサーバー証明書は、有効期限が切れる前に必ずローテーションしてください。これにより、安全な受信接続が維持され、Webクライアントが有効なSSL証明書を使用してデータベースにアクセスできるようになります。
インスタンスがGCPマネージドキーの代わりにカスタマーマスターキー (CMK) を使用して暗号化されているかどうかを確認します。
Google Cloud SQL は、デフォルトで Google が管理する鍵を使用して保存データを暗号化し、ユーザーの介入は必要ありません。ただし、暗号化を完全に制御する必要がある場合は、クラウド キー管理サービス (Cloud KMS) を通じて CMK を使用できます。これは、特に厳しいセキュリティとコンプライアンスのニーズがあるエンタープライズ環境において、機密データやミッションクリティカルなデータに最適です。
データの暗号化と復号化プロセスの制御を強化するために、Google Cloud SQL データベース インスタンスが CMK で暗号化されていることを確認します。これらの CMK は、Cloud KMS を通じて作成および管理できます。Cloud KMS は、制御された鍵のローテーションおよび取り消し機能とともに、安全かつ効率的な鍵管理を提供します。
インスタンスが非暗号化モードでの接続を許可するかどうかを確認します。
Cloud SQL データベース接続が中間者（MITM）攻撃に対して脆弱である場合、ユーザーの認証情報、クエリ、結果などの機密データが漏洩する可能性があります。転送中のデータを保護するために、特にパブリック IP アドレスを使用する場合は、Cloud SQL データベース インスタンスへのすべての受信接続に SSL/TLS を適用することを強くおすすめします。
不正アクセスや盗聴を防ぐために、Cloud SQLデータベースインスタンスへのすべての受信接続にSSL/TLS暗号化が適用されていることを確認してください。SSL/TLSを強制するには、すべてのSQLデータベースインスタンスに対してSSL強制モードを「ENCRYPTED_ONLY」に設定します。
インスタンスのipAddressタイプのいずれかがPRIMARYとして設定されているかどうかを確認します。
各Google Cloud SQLデータベースインスタンスには、デフォルトでパブリック IP アドレスが割り当てられます。アプリケーションの攻撃対象領域を最小限に抑えるには、Cloud SQLデータベースにはプライベートIPのみを使用することをおすすめします。プライベートIPはクラウドネットワークのセキュリティを強化し、データベースアプリケーションのレイテンシーを短縮します。
セキュリティを強化し、潜在的な脅威への露出を減らすために、Google Cloud SQLデータベースインスタンスがパブリックIPではなくプライベートIPアドレスを使用するように構成されていることを確認してください。
インスタンスがIPv4対応として構成されており、承認されたネットワークIPアドレスがワイルドカードであるかどうかを確認します。
SQLデータベースインスタンスへのパブリックアクセス (0.0.0.0/0 など) を許可すると、有効な資格情報が必要になりますが、IPv4クライアントはログインを試行できます。攻撃対象領域を減らすには、信頼できるIPとネットワークのみをアクセス用にホワイトリストに登録する必要があります。
Google Cloud SQLデータベースインスタンスが、承認されたIPアドレスと信頼できるネットワークからの接続のみを受け入れるように設定されていることを確認します。
インスタンスの構成で削除保護が無効になっているかどうかを確認します。
インスタンスの削除保護を使用すると、既存のインスタンスと新しいインスタンスが誤って削除されるのを防ぐことができます。インスタンス削除保護を使用すると、アプリケーションやサービスにとって重要なインスタンスを保護できます。
削除保護を有効にして、インスタンスが誤って削除されるのを防ぎます。
MySQL インスタンスの local_infile フラグがオフに設定されているかどうかを確認します。
MySQL の local_infile フラグは、LOAD DATA INFILE ステートメントがクライアント側のファイルからデータをロードできるかどうかを制御します。この機能を有効にすると、攻撃者がサーバーから任意のファイルを読み取ることができる可能性があり、セキュリティ リスクが生じます。
潜在的なセキュリティ脆弱性を防ぐために、CloudSQL MySQL インスタンス設定で local_infile フラグをオフに設定して無効にします。
MySQL インスタンスに対して Skip_show_database フラグが有効になっているかどうかを確認します。
skip_show_database フラグは、SHOW DATABASES 権限を持たないユーザーが SHOW DATABASES ステートメントを通じてデータベース名を表示できないようにします。これにより、権限のないユーザーが CloudSQL インスタンス内のデータベース名を検出することが制限されます。
CloudSQL MySQL インスタンスで Skip_show_database フラグを有効にして、権限のないユーザーがデータベース名を検出できないようにします。
PostgreSQL インスタンスに対して log_checkpoints フラグが有効になっているかどうかを確認します。
log_checkpoints フラグは、チェックポイント操作をサーバー ログに記録します。チェックポイント操作では、変更されたすべてのデータがディスクに書き込まれ、データの耐久性が確保されます。これらの操作をログに記録すると、データベースのパフォーマンスと回復プロセスを監視するのに役立ちます。
CloudSQL PostgreSQL インスタンスの log_checkpoints フラグを有効にしてチェックポイント操作を追跡し、パフォーマンスのモニタリングとトラブルシューティングを向上させます。
PostgreSQL インスタンスに対して log_connections フラグが有効になっているかどうかを確認します。
log_connections フラグは、成功した各クライアント接続をサーバー ログに記録します。これにより、データベースにアクセスしているユーザーを追跡し、セキュリティの監視と監査機能が強化されます。
セキュリティ監視と接続追跡を強化するには、CloudSQL PostgreSQL インスタンスで log_connections フラグを有効にします。
PostgreSQL インスタンスに対して log_disconnections フラグが有効になっているかどうかを確認します。
log_disconnections フラグは、各セッションの継続時間も含めて、セッションの終了をサーバー ログに記録します。これは、データベース セッションのライフ サイクルの全体像を提供することで、log_connections フラグを補完します。
CloudSQL PostgreSQL インスタンスで log_disconnections フラグを有効にして、セキュリティ監視のためにセッションの継続時間と終了を追跡します。
PostgreSQL インスタンスに対して log_executor_stats フラグが無効になっているかどうかを確認します。
log_executor_stats フラグは、エグゼキュータのパフォーマンス統計をログに記録します。これにより、運用環境で過剰なログ エントリが生成され、パフォーマンスに影響を与える可能性があります。このレベルの詳細は通常、特定のデバッグ セッション中にのみ必要になります。
本番環境の CloudSQL PostgreSQL インスタンスで log_executor_stats フラグを無効にして、過剰なロギングと潜在的なパフォーマンスへの影響を防ぎます。
PostgreSQL インスタンスに対して log_hostname フラグが有効かどうかを確認します。
log_hostname フラグは、IP アドレスだけでなく、接続および切断メッセージ内のクライアントのホスト名を記録します。これにより、セキュリティの監視と監査を目的としたより詳細な情報が提供されます。
CloudSQL PostgreSQL インスタンスの log_hostname フラグを有効にして、接続ログにクライアントのホスト名をキャプチャし、セキュリティ追跡を強化します。
PostgreSQL インスタンスに対して log_lock_waits フラグが有効になっているかどうかを確認します。
log_lock_waits フラグは、長いロック待機時間を記録します。これは、ロック競合によって引き起こされる潜在的なデータベース デッドロックやパフォーマンスのボトルネックを特定するのに役立ちます。
CloudSQL PostgreSQL インスタンスで log_lock_waits フラグを有効にして、ロック関連のパフォーマンスの問題を検出してトラブルシューティングします。
PostgreSQL インスタンスに対して log_min_duration_statement フラグが無効になっているかどうかを確認します。
log_min_duration_statement フラグは、指定された期間を超えて実行されるステートメントをログに記録します。パフォーマンスのチューニングには役立ちますが、SQL ステートメントに機密情報が含まれている場合、ログ内の機密データが漏洩する可能性があります。
機密データを処理する場合は、本番環境の CloudSQL PostgreSQL インスタンスの log_min_duration_statement フラグを無効にするか、真に問題のあるクエリのみをキャプチャするために高い値に設定します。
PostgreSQL インスタンスに対して log_parser_stats フラグが無効になっているかどうかを確認します。
log_parser_stats フラグは、パーサーのパフォーマンス統計をログに記録します。これにより、運用環境で過剰なログ エントリが生成される可能性があります。このレベルの詳細は通常、特定のデバッグ セッション中にのみ必要になります。
本番環境の CloudSQL PostgreSQL インスタンスで log_parser_stats フラグを無効にして、過剰なロギングと潜在的なパフォーマンスへの影響を防ぎます。
log_temp_files フラグが PostgreSQL インスタンスに対して適切に構成されているかどうかを確認します。
log_temp_files フラグは、指定されたサイズを超える一時ファイルの使用をログに記録します。これは、データベースのパフォーマンスに影響を与える可能性がある、一時的な操作に過剰なディスク容量を必要とするクエリを特定するのに役立ちます。
大規模な一時ファイルの使用状況を追跡し、最適化が必要なクエリを特定するには、CloudSQL PostgreSQL インスタンスで log_temp_files フラグを構成します。
pgAudit 拡張機能が PostgreSQL インスタンスに対して有効になっているかどうかを確認します。
pgAudit 拡張機能は、規制遵守に必要となる詳細なセッションおよびオブジェクト監査ログ機能を提供します。 PostgreSQL のネイティブ ロギング機能よりも包括的な監査を提供します。
CloudSQL PostgreSQL インスタンスで pgAudit 拡張機能を有効にして、コンプライアンス要件を満たし、セキュリティ監視機能を強化します。
包含データベース認証が SQL Server インスタンスに対して無効になっているかどうかを確認します。
包含データベース認証では、サーバーのマスター データベースではなく、データベース自体にユーザーの資格情報が保存されます。これにより、潜在的な認証情報の漏洩や一元的な認証管理の課題など、セキュリティ リスクが生じる可能性があります。
認証の一元的な制御を維持するために、包含データベース認証フラグをオフに設定して、CloudSQL SQL Server インスタンスの包含データベース認証をオフにします。
SQL Server インスタンスに対してクロスデータベース所有権チェーンが無効になっているかどうかを確認します。
データベース間の所有権チェーンを使用すると、あるデータベースで権限を持つユーザーが、明示的な権限なしで別のデータベースのオブジェクトにアクセスできるようになります。これにより、権限昇格やデータベース境界を越えた意図しないデータ アクセスが発生する可能性があります。
クロス データベース所有権チェーン フラグをオフに設定して、CloudSQL SQL Server インスタンスのクロスデータベース所有権チェーンをオフにし、データベース間の適切な権限境界を確保します。
SQL Server インスタンスに対して外部スクリプトの実行が無効になっているかどうかを確認します。
外部スクリプト有効フラグを使用すると、SQL Server 内で R や Python などの言語でスクリプトを実行できます。この機能はデータ分析には強力ですが、SQL Server のセキュリティ境界外で潜在的に悪意のあるコードの実行を許可することで攻撃対象領域を拡大します。
特に必要な場合を除き、外部スクリプト有効フラグをオフに設定して CloudSQL SQL Server インスタンスの外部スクリプトの実行を無効にし、有効にした場合は、外部スクリプトを実行できるユーザーに対する厳密な制御を実装します。
SQL Server インスタンスのリモート アクセスが無効になっているかどうかを確認します。
リモート アクセス フラグを使用すると、ストアド プロシージャをリモート サーバーから実行できるようになります。有効にすると、コードのリモート実行が許可され、データベースが潜在的なセキュリティ リスクにさらされる可能性があります。
リモート アクセス フラグをオフに設定して CloudSQL SQL Server インスタンスのリモート アクセスを無効にし、リモート サーバーからの不正なストアド プロシージャの実行を防ぎます。
SQL Server インスタンスに対してトレース フラグ 3625 が無効になっているかどうかを確認します。
トレース フラグ 3625 は、SQL Server 例外が発生したときにユーザーに返される情報を制限します。これは本番環境で機密情報の漏洩を防ぐのに役立ちますが、適切な監査とセキュリティ監視に必要な詳細を隠すこともできます。
トレース フラグ 3625 が環境のセキュリティ要件に従って適切に設定されていることを確認してください。包括的な監査ログが必要な環境の場合は、完全なエラー情報が確実に取得されるように、このフラグを無効にすることを検討してください。
ユーザー オプション フラグが SQL Server インスタンスに設定されていないかどうかを確認します。
ユーザー オプション フラグは、すべてのユーザーのデフォルト設定を設定します。これをサーバー レベルで構成すると、予期しない動作や潜在的なセキュリティ問題が発生する可能性があります。ユーザー オプションをより詳細なレベルで管理することをお勧めします。
CloudSQL SQL Server インスタンスのセキュリティのベスト プラクティスを維持するために、ユーザー オプションという名前のデータベース フラグを削除して、ユーザー オプション フラグが設定されていないことを確認します。
クラスターの Pub/Sub 通知が無効になっているかどうかを確認します。
Pub/Sub 経由で Google Kubernetes Engine (GKE) クラスタ通知を構成すると、アップグレード、セキュリティ アップデート、新しいリリースに関するアラートがタイムリーに送信され、ダウンタイムが最小限に抑えられ、リスクと最適化の機会が常に通知されます。
GKE クラスタの重要なアラート通知を有効にして、アップグレード、セキュリティ アップデート、その他の重要な情報に関する重要な Pub/Sub メッセージを Google Cloud から受信します。
クラスタのノード内の可視性が無効になっているかどうかを確認します。
ノード内の可視性により、同じノード上であっても、すべてのポッド間のトラフィックが Google Cloud Virtual Private Cloud (VPC) ネットワーク経由でルーティングされ、一貫したファイアウォール ルール、フロー ログ、パケット ミラーリングが保証されます。
GKE クラスタでノード内の可視化を有効にし、VPC フロー ログとツールを使用してノード内のポッド トラフィックを監視および保護します。
クラスタのワークロード脆弱性スキャンが無効になっているかどうかを確認します。
GKE ワークロードの脆弱性スキャンを有効にして、コンテナ イメージとパッケージのセキュリティ問題を検出して修正し、リスクを軽減します。各ノードにデプロイされたスキャン ポッドを使用して、基本スキャンまたは高度なスキャンを選択します。
GKE クラスタのワークロード脆弱性スキャンを有効にして、コンテナ イメージの脆弱性を特定し、セキュリティ コンプライアンスを確保し、潜在的な脅威からクラスタを保護します。
クラスタのロギング機能が無効になっているかどうかを確認します。
GKE アドオンである Cloud Logging は、ログと指標を収集してリモート アグリゲータに送信し、改ざんリスクを軽減します。クラスタの健全性、パフォーマンス、セキュリティに関する洞察を提供し、トラブルシューティング、プロアクティブなメンテナンス、コンプライアンスを支援します。
GKE クラスタのロギングを有効にして、Kubernetes アプリケーションと基盤となる GKE インフラストラクチャからログを収集します。
クラスタの監視機能が無効になっているかどうかを確認します。
GKE アドオンである Cloud Monitoring は、アプリケーションとインフラストラクチャから指標を収集します。これがなければ、パフォーマンスの問題、セキュリティの脅威、障害を特定するのは困難です。モニタリングを有効にすると、クラスタの健全性、信頼性、パフォーマンスに関する洞察が得られ、トラブルシューティング、プロアクティブなメンテナンス、コンプライアンスに役立ちます。
Kubernetes アプリケーションと、それをサポートする基盤となる GKE インフラストラクチャの両方から指標を収集するには、GKE クラスタの Cloud Monitoring を必ず有効にしてください。
クラスタのセキュリティ体制機能が無効になっているかどうかを確認します。
セキュリティ体制の監査は、ベスト プラクティスに照らして GKE ワークロードを評価し、問題をプロアクティブに解決するのに役立つ脆弱性の一元的なビューを提供します。これにより、安全なコンテナ化環境が保証され、GKE Enterprise Edition クラスタでのみ使用できます。
GKE クラスタの Security Posture ダッシュボードを有効にします。 Cloud Logging、Policy Controller、Binary Authorization と統合して、脆弱性、構成ミス、コンプライアンス リスクを特定し、セキュリティと規制遵守を強化します。
Google Cloud コンソールの [セキュリティ] セクションで、整合性モニタリング機能のステータスを確認します。 Google Cloud Monitoring サービスを使用してシールドされたクラスタ ノードのランタイム ブート整合性を監視し、自動的にチェックするには、Google Kubernetes Engine (GKE) クラスタ ノードの整合性モニタリング機能が有効になっていることを確認してください。
クラスタ ノードの整合性モニタリングを有効にします。
強力な暗号化 ID を提供するために、Google Kubernetes Engine (GKE) クラスター プール ノードがシールドされていることを確認してください。これにより、攻撃者がノードの認証情報を抽出できたとしても、GKE クラスタ内のノードになりすますことが制限されます。
シールドされた GKE クラスタ ノードを構成します。シールドされた GKE ノードの構成属性値を確認します。
マスター承認済みネットワークを追加すると、Google Kubernetes Engine (GKE) クラスターにネットワーク レベルの保護と追加のセキュリティ上の利点が提供されます。承認されたネットワークは、安全なネットワークから発信されるものなど、信頼できる IP アドレスの特定のセットへのアクセスを許可します。これは、クラスタの認証または認可メカニズムに脆弱性があった場合に、GKE クラスタへのアクセスを保護するのに役立ちます。
マスター承認ネットワーク属性値を確認します。 マスター承認ネットワークの値が無効に設定されている場合、インターネット上の誰でもクラスター コントロール プレーンへのネットワーク接続を実行できます。
インスタンスがリリース チャネルを Rapid として設定しているかどうかを確認します。
Google Kubernetes Engine (GKE) リリース チャネルは、新機能と安定性のバランスを維持するためにクラスターのバージョンを自動的に選択します。 Stable チャネルでは、信頼性が証明されているため、更新の数が少なくなり、運用環境に最適です。 Regular チャネルでは、新しい機能を備えたより頻繁な更新が提供されますが、検証は少なくなります。すべてのチャネルは重要なセキュリティ パッチを受け取ります。
バージョン管理を簡素化し、GKE クラスタのアップグレードを自動化するには、通常リリース チャネルまたは安定版リリース チャネルに登録してください。
クラスタ ノードの自動アップグレード プロパティが無効になっているかどうかを確認します。
GKE クラスタ ノードの自動アップグレードを有効にすると、Kubernetes がサポートされている最新バージョンに自動的かつ安全に更新され、アップグレード管理が合理化されます。これにより、最新のセキュリティ修正、機能、拡張機能に確実にアクセスできるようになります。
GKE クラスタ内のすべてのノードの自動アップグレード機能を有効にして、サポートされている最新の Kubernetes バージョンを最新の状態に保ちます。
クラスターのアプリケーション層のシークレット暗号化が無効になっているかどうかを確認します。
デフォルトでは、Kubernetes はシークレットを Base64 でエンコードされたプレーンテキストとして etcd に保存します。アプリケーション層のシークレット暗号化を有効にすると、Google 管理のキーまたは顧客管理の暗号化キーを使用してシークレットを暗号化することにより、セキュリティ層が追加されます。これにより、たとえ誰かが etcd ストレージにアクセスしたとしても、パスワード、OAuth トークン、SSH キーなどの機密情報への不正アクセスが防止されます。
GKE クラスタのアプリケーション層シークレット暗号化を有効にして、Kubernetes の機密シークレットを保護します。制御を強化するには、顧客管理の暗号化キーの使用を検討してください。
ネットワーク ポリシーが GKE クラスタで有効になっているかどうかを確認します。
ネットワーク ポリシーを使用すると、クラスター内のポッド間の通信を制御できます。ネットワーク ポリシーが有効になっていないと、すべてのポッドが相互に通信できるため、アプリケーション コンポーネント間で不正アクセスが発生する可能性があります。
GKE クラスタでネットワーク ポリシーを有効にして、ポッド間の通信に対するきめ細かい制御を実装し、クラスタのセキュリティ体制を向上させます。
ファイルストアの削除保護が無効になっているかどうかを確認します。
削除保護を有効にすると、ファイルストアインスタンスは誤って削除されないように保護されます。これにより、機能が明示的に無効にされない限り、ユーザーは Google Cloud コンソール、CLI、または API を介してインスタンスを削除できなくなります。
誤って削除されないように、ファイルストアインスタンスで削除保護機能を有効にします。
ファイルストアのオンデマンド バックアップと復元が設定されているかどうかを確認します。
オンデマンドファイルストアバックアップは外部に保存され、最初のバックアップは完全コピーで、後続のバックアップは変更のみをキャプチャします。誤って削除、破損、災害が発生した場合でも、ポイントインタイムのリカバリと迅速な復元を可能にすることで重要なデータ保護を提供し、最小限のダウンタイムとビジネスの継続性を保証します。
Filestore のオンデマンド バックアップと復元を利用して、プロビジョニングされた容量やアプリケーションのパフォーマンスに影響を与えることなく、データ保護を強化し、災害復旧を支援し、コンプライアンス規制を順守します。
ファイルストアの顧客管理の暗号化キー (CMEK) が構成されているかどうかを確認します。
Google Cloud は、Google が管理する鍵を使用して保存されたデータを自動的に暗号化します。さらに制御するには、安全な鍵管理、ローテーション、取り消しのために、Google Cloud Key Management Service (KMS) 経由で CMEK を使用することを検討してください。
制御とセキュリティコンプライアンスを強化するには、Google が管理する暗号鍵の代わりに CMEK を使用します。
Cloud KMS 鍵のローテーション間隔が 90 日未満かどうかを確認します。
セキュリティとコンプライアンスの要件に合わせて、Cloud KMS 鍵を 90 日ごとにローテーションします。これらのキーはデータの暗号化と復号化に使用され、更新されたキー素材を含む新しいバージョンがローテーションのために設定された間隔で自動的に作成されます。
ユーザー管理の Cloud KMS 鍵は強力ですが、扱いを誤ると危険です。最適なローテーションにより、妥協の可能性が減少します。
Cloud KMS 鍵が公開されているかどうかを確認します。
Cloud KMS 鍵の IAM ポリシーでアクセスを制限し、匿名ユーザーや一般ユーザーが鍵にアクセスできないようにしてください。 allUsers および allAuthenticatedUsers のアクセス許可を削除して、これらのユーザーによるアクセスを防止します。 allUsers ロールにはインターネット ユーザーが含まれ、allAuthenticatedUsers ロールには Google Cloud ログインを持つユーザーとサービス アカウントが含まれます。
データ侵害を避けるために、Cloud KMS リソースが allUsers ロールと allAuthenticatedUsers ロールへのアクセスを許可しないようにしてください。
自動ランタイム セキュリティ アップデートが Cloud Run 機能に設定されているかどうかを確認します。
Google は、定期的なメンテナンスと安定性テストを通じて Cloud Run の機能を更新し、保護します。これには、関数の安全な環境を確保するための、OS やパッケージなどの実行環境の更新が含まれます。 Google Cloud は、関数ランタイム環境のセキュリティ アップデートも自動的に管理します。
Cloud Run 機能の自動ランタイム セキュリティ アップデートを有効にして、手動介入を必要とせずに継続的なセキュリティと脆弱性からの保護を確保します。
サーバーレス VPC アクセスが機能に対して設定されているかどうかを確認します。
サーバーレス VPC アクセスにより、VPC ネットワークと Cloud Run 機能などのサーバーレス環境との間の安全かつ高速な接続が可能になります。コネクタは 2 つのセットアップ間のトラフィックを処理します。 Google Cloud プロジェクトで VPC コネクタを作成し、それを VPC ネットワークとリージョンにリンクし、高速で安全な送信ネットワーク トラフィックにコネクタを使用するようにサーバーレス サービスを設定するだけです。
VPC ネットワークに直接接続できるように、サーバーレス VPC アクセスを使用して Cloud Run 機能を構成します。これにより、VM インスタンス、Memorystore インスタンス、他のクラウド リソースの内部 IP アドレスなど、他の VPC リソースへの接続が可能になります。
機能に無制限のネットワーク アクセスがあるかどうかを確認します。
無制限の送信ネットワーク アクセスは、データ盗難、中間者攻撃、サービス妨害攻撃などの有害な行為につながる可能性があります。必要なリソースへのアクセスを制限すると、これらのリスクが軽減されます。
機能を保護し、コストを節約するために、送信ネットワーク アクセスを制限します。 VpcConnectorEgressSettings を利用して外部トラフィックを制限し、外部ネットワーク通信を回避します。
関数が古い実行ランタイム環境を使用していないかどうかを確認します。
Cloud Run 機能の第 2 世代では、コールド スタートと実行時間の高速化、幅広いランタイム環境、ネットワーキングと Google Cloud サービスとの統合の強化、モニタリング ツールとデバッグ ツールの強化など、第 1 世代と比べて大幅な改善が行われています。パフォーマンス、柔軟性、開発および運用プロセスをよりスムーズにするために、第 2 世代にアップグレードすることを強くお勧めします。 Google Cloud Run と Google Cloud Eventarc の長所を組み合わせ、同時処理、トラフィック分散、処理時間の延長などの機能を提供します。
Cloud Run の機能を最新のランタイム バージョンにアップグレードすると、セキュリティ、パフォーマンスが向上し、新機能にアクセスできるようになります。古いバージョンはサポートされなくなっており、安全性と効率性が低下する可能性があります。
関数が非推奨のランタイム バージョンを使用しているかどうかを確認します。
Cloud Run 機能の最新の言語ランタイムに更新することは、セキュリティの向上、パフォーマンスの向上、新しい機能やライブラリへのアクセスのために不可欠です。これにより、バグ修正、最適化、他のサービスとの互換性が確保され、脆弱性が最小限に抑えられ、サーバーレス アプリケーションがスムーズかつ効率的に維持されます。
ベスト プラクティスに従い、新機能にアクセスするには、Cloud Run 機能に常に最新の言語ランタイムを使用してください。
インスタンスの最大数が Cloud Run サービスに構成されているかどうかを確認します。
インスタンスの最大数を構成すると、コストを管理し、サービスが特定の制限を超えてスケールしないようにするのに役立ちます。これは、予算管理とリソース割り当てにとって重要です。
コストとリソース使用量を効果的に管理するには、Cloud Run サービスのインスタンスの最大数を設定します。
Cloud Run サービスの自動ランタイム セキュリティ アップデートが無効になっているかどうかを確認します。
自動ランタイム セキュリティ アップデートを有効にすると、Cloud Run サービスで常に最新のセキュリティ パッチが実行され、脆弱性のリスクが軽減され、全体的なセキュリティが向上します。
Cloud Run サービスのランタイム セキュリティの自動更新を有効にして、セキュリティとコンプライアンスを維持します。
Cloud Run サービスに対してバイナリ認証が無効になっているかどうかを確認します。
Binary Authorization により、信頼できるコンテナ イメージのみが Cloud Run サービスにデプロイされるようになり、未検証のコードや有害な可能性のあるコードの実行を防止してセキュリティが強化されます。
Cloud Run サービスのバイナリ認証を有効にして、信頼できる検証済みのコンテナ イメージのみがデプロイされるようにします。
顧客管理の暗号鍵（CMEK）が Cloud Run サービスに使用されているかどうかを確認します。
CMEK を使用すると、データの保護に使用される暗号化キーを完全に制御でき、セキュリティと規制要件への準拠が強化されます。
Cloud Run サービスに CMEK を使用して、セキュリティとコンプライアンスを強化します。
Cloud Run サービスの送信ネットワーク アクセスが制限されているかどうかを確認します。
送信ネットワーク アクセスを制限すると、攻撃対象領域を最小限に抑え、Cloud Run サービスからの不正なデータの流出を防ぐことができます。
Cloud Run サービスの送信ネットワーク アクセスを制限して、セキュリティを強化し、不正なデータ漏洩を防ぎます。
Cloud Run サービスに使用されるランタイム バージョンが非推奨かどうかを確認します。
非推奨のランタイム バージョンを使用すると、Cloud Run サービスがセキュリティの脆弱性や互換性の問題にさらされる可能性があります。セキュリティと安定性を確保するには、サポートされている最新のランタイム バージョンを使用することが重要です。
セキュリティと安定性を確保するために、サポートされている最新のランタイム バージョンを使用するように Cloud Run サービスを更新します。
Cloud Run サービスが一般公開されているかどうかを確認します。
Cloud Run サービスを一般公開すると、潜在的なセキュリティ リスクにさらされる可能性があります。セキュリティを強化するには、機密サービスへの一般のアクセスを制限することが重要です。
Cloud Run サービスへのパブリック アクセスを制限して、セキュリティを強化し、不正アクセスを防ぎます。
GCP ストレージ バケットの IAM ポリシーで、管理者権限を付与するポリシーを確認します。
ストレージ バケットに管理者権限を付与すると、不正アクセスや潜在的なデータ侵害につながる可能性があります。
管理者権限を絶対に必要とするユーザーのみに制限します。
GCP ストレージ バケットのアクセス ポリシーをチェックして、一般公開されているかどうかを確認します。
パブリックにアクセスできるストレージ バケットでは、機密データが権限のないユーザーに公開される可能性があります。
ストレージ バケットへのパブリック アクセスを制限し、承認されたユーザーのみがアクセスできるようにします。
顧客管理の暗号鍵 (CMEK) を使用したオブジェクト暗号化について、GCP ストレージ バケットの暗号化設定を確認します。
CMEK によるオブジェクト暗号化を有効にすると、データのセキュリティ層が追加されます。
すべてのストレージ バケットに対して CMEK を使用したオブジェクト暗号化を有効にして、データ セキュリティを強化します。
GCP ストレージ バケットの使用状況とストレージ ログのロギング設定を確認します。
使用状況とストレージのログを有効にすると、アクセスと使用パターンの監視に役立ち、セキュリティと最適化のための洞察が得られます。
すべてのストレージ バケットの使用状況とストレージ ログを有効にして、アクセスと使用パターンを監視および分析します。
GCP ストレージ バケットの均一なバケットレベルのアクセス設定を確認します。
均一なバケットレベルのアクセスにより、バケット内のすべてのオブジェクトに均一に IAM ポリシーが適用され、権限管理が簡素化されます。
均一なバケットレベルのアクセスを有効にして、権限管理を簡素化し、セキュリティを強化します。
GCP ストレージ バケットのクロスオリジン リソース共有 (CORS) 構成を確認します。
CORS 構成により、ストレージ バケットがクロスオリジン リクエストを処理できるようになります。これは Web アプリケーションに必要となる可能性があります。
CORS 設定を適切に構成して、セキュリティを維持しながらクロスオリジン リクエストを有効にします。
Pub/Sub トピックをチェックし、Cloud KMS 経由で顧客管理の暗号鍵（CMEK）を使用して暗号化されていることを確認します。
Cloud Pub/Sub トピックは、デフォルトで Google 管理のキーを使用します。データの暗号化とコンプライアンスをより細かく制御するには、Cloud KMS を通じて CMEK を使用するようにトピックを構成します。
Cloud KMS 経由で CMEK を使用するように Cloud Pub/Sub トピックを構成し、データ セキュリティと鍵管理を強化します。
Cloud Pub/Sub トピックの IAM ポリシーをチェックして、パブリック アクセスのあるトピックを特定します。
Cloud Pub/Sub トピックへのパブリック アクセスを許可すると、機密データが公開され、無許可の公開または購読が許可される可能性があります。この構成では、重大なセキュリティ リスクが発生する可能性があります。
承認されたプリンシパルのみが権限を持つようにし、パブリック アクセスを削除することで、Cloud Pub/Sub トピックへのアクセスを制限します。
Cloud DNS マネージド ゾーンで DNSSEC が無効になっているかどうかを確認します。
DNSSEC は、DNS 応答を検証できるようにすることで、ドメイン ネーム システム (DNS) プロトコルにセキュリティを追加します。これにより、ウェブ トラフィックが正しいサーバーにルーティングされるようになり、DNS スプーフィングやキャッシュ ポイズニング攻撃から保護されます。
Cloud DNS ゾーンの DNSSEC を有効にして、DNS セキュリティを強化し、DNS スプーフィングやその他の攻撃から保護します。
Cloud DNS マネージド ゾーンでの鍵署名に非推奨のアルゴリズムが使用されているかどうかを確認します。
キー署名アルゴリズムは、DNSSEC セキュリティにとって重要です。 RSASHA1 などの非推奨のアルゴリズムを使用すると、最新の暗号化攻撃に対する安全性が低いと考えられているため、DNS インフラストラクチャのセキュリティが危険にさらされる可能性があります。
鍵署名アルゴリズムを更新して、RSASHA1 などの非推奨のアルゴリズムではなく、RSASHA256 や RSA-SHA512 などのより安全なアルゴリズムを使用します。
Cloud DNS マネージド ゾーンのゾーン署名に非推奨のアルゴリズムが使用されているかどうかを確認します。
ゾーン署名アルゴリズムは、DNSSEC セキュリティに不可欠です。 RSASHA1 などの非推奨のアルゴリズムを使用すると、暗号化攻撃に対する DNS ゾーンのセキュリティ体制が弱まる可能性があります。
ゾーン署名アルゴリズムを更新して、RSASHA1 などの非推奨のアルゴリズムではなく、RSASHA256 や RSASHA512 などのより安全なアルゴリズムを使用します。
roles/iam.serviceAccountUser ロールまたはroles/iam.serviceAccountTokenCreatorロールを持つプリンシパルをチェックします。
サービス アカウント ユーザー ロールとトークン作成者ロールは、プリンシパルにサービス アカウントになりすまして OAuth トークンを作成する機能を付与します。これらの強力な権限は、不適切に割り当てられた場合、権限昇格を可能にする可能性があります。
これらのロールは、サービス アカウントとして機能する機能を絶対に必要とする信頼できるプリンシパルのみに制限します。定期的に割り当てを確認し、最小権限の原則を実装してください。
重要な連絡先が操作、セキュリティ、請求に関する通知用に設定されているかどうかを確認します。
重要な連絡先は、重要な通知が適切なチームに届くようにします。適切に構成しないと、セキュリティ上の問題、請求上の問題、または運用上のインシデントに関する重要なアラートが見逃される可能性があります。
プロジェクトの重要な連絡先を構成して、GCP リソースのさまざまな側面を担当する適切な担当者またはチームに通知が確実にルーティングされるようにします。
3 つの監査ログ タイプ (管理アクティビティ、データ アクセス、システム イベント) がすべて有効かどうかを確認します。
包括的な監査ログは、セキュリティ監視、インシデント対応、コンプライアンスに不可欠です。適切な監査ログがなければ、セキュリティ インシデントを調査したり、コンプライアンス監査の証拠を提供したりすることが困難になります。
すべてのサービスの 3 種類の監査ログ (管理アクティビティ、データ アクセス、システム イベント) をすべて有効にして、GCP 環境内のアクティビティの完全な監査証跡を維持します。
一般向けメール ドメイン (gmail.com、yahoo.com、hotmail.com、または Outlook.com) が GCP リソースへのアクセスに使用されているかどうかを確認します。
クラウド リソースへのアクセスに個人の電子メール アカウントを使用すると、セキュリティと管理の課題が生じます。これらのアカウントには集中管理が欠如しており、オフボーディング プロセスが複雑で、組織のセキュリティ ポリシーを満たしていない可能性があります。
GCP リソースへのアクセスには、個人のメール アカウントではなく、企業のメール アカウントまたは組織の ID プロバイダとのフェデレーション ID を使用します。
プロジェクトにアクセス承認が設定されているかどうかを確認します。
アクセス承認を使用すると、Google 担当者によるデータまたは設定へのアクセスを明示的に承認できます。アクセス承認がないと、Google スタッフはトラブルシューティング中やサポート活動中に明示的な承認なしにコンテンツにアクセスする可能性があります。
プロジェクトのアクセス承認を有効にして、特に機密性の高いワークロードや規制された環境において、Google 担当者がいつコンテンツにアクセスできるかを制御します。
プリンシパルが KMS Admin ロールと KMS CryptoKey ロールの両方に割り当てられているかどうかを確認します。
職務の分離は、1 人の個人がプロセス全体を制御することを防ぐセキュリティ原則です。プリンシパルがキー管理サービス (KMS) 管理者ロールと暗号化操作ロールの両方を持っている場合、プリンシパルは、セキュリティ チェックとバランスをバイパスして、キーを作成して使用できます。
異なるプリンシパルが KMS 管理と暗号化操作の責任を負うことを保証することで、職務の分離を実装します。これにより、相互監視を通じてセキュリティが強化されます。
プリンシパルに基本的な役割 (役割/所有者、役割/編集者、役割/閲覧者) が割り当てられているかどうかを確認します。
基本的な役割は、最小特権の原則に違反する広範な権限を提供します。特定のサービスやアクションではなく、プロジェクト内のすべてのリソースへのアクセスが許可されるため、偶発的または悪意のある悪用のリスクが高まります。
基本的な役割を、特定のタスクに必要な権限のみを付与する事前定義された役割またはカスタムの役割に置き換えます。これにより、リスク面が軽減され、セキュリティ体制が向上します。
サービス アカウントに管理者ロールまたは特権ロールが付与されているかどうかを確認します。
管理者ロールを持つサービス アカウントは特権操作を実行できるため、サービス アカウントが侵害された場合に特権昇格が可能になる可能性があります。サービス アカウントは、最小特権の原則に従う必要があります。
管理者ロールを持つサービス アカウントを確認し、権限をその機能に必要な権限のみに減らします。サービス アカウント キーの代わりに、GKE のワークロード ID またはコンピューティング リソースのマネージド ID の使用を検討してください。
サービス アカウント キーが 90 日より古いかどうかを確認します。
サービス アカウント キーを定期的にローテーションすると、キーが侵害された場合に攻撃者が侵入する機会が制限されます。キーの有効期間が長いと、特にキーがダウンロードまたは共有されている場合、セキュリティ上のリスクが生じます。
サービス アカウント キーのキー ローテーション ポリシーを実装し、少なくとも 90 日ごとにキーをローテーションします。可能な場合は、Workload Identity フェデレーションなどの代替認証方法の使用を検討してください。
内部 Google Cloud サービス アカウントにユーザー管理のキーが存在するかどうかを確認します。
内部サービス アカウント (iam.gserviceaccount.com で終わるものなど) のユーザー管理キーは、不必要なセキュリティ リスクを引き起こします。これらの内部サービス アカウントは Google Cloud サービスによって管理されることを目的としており、手動で鍵を管理すると構成ミスが発生する可能性があります。
内部サービス アカウントのユーザー管理キーの作成は避けてください。 Workload Identity フェデレーション、偽装、接続されたサービス アカウントなど、サービスに適した代替認証方法を使用します。
BigQuery 管理者、dataEditor、または dataOwner ロールを持つプリンシパルを確認します。
BigQuery 管理ロールは、データセット、テーブル、クエリ データを管理するための広範な権限を付与します。不正なデータ アクセスや変更を防ぐために、これらの強力な役割は少数の信頼できる管理者に限定する必要があります。
BigQuery 管理者ロールを持つプリンシパルの数を制限します。 bigquery.dataViewer などのより詳細なロール、または特定のタスクに必要な権限のみを持つカスタム ロールの使用を検討してください。
roles/pubsub.admin ロールを持つプリンシパルを確認します。
Pub/Sub 管理者ロールは、トピックとサブスクリプションに対する完全な制御を付与します。これには、これらのリソースへのアクセスを作成、変更、削除、管理する機能も含まれます。過剰な管理者は、メッセージ配信システムに不正な変更が加えられるリスクを高めます。
Pub/Sub 管理者ロールを持つプリンシパルの数を制限します。メッセージを公開または消費することのみが必要なアカウントには、pubsub.publisher や pubsub.subscriber など、より具体的なロールを使用します。
roles/bigtable.admin ロールを持つプリンシパルを確認します
Bigtable 管理者ロールは、インスタンスとテーブルの作成、変更、削除、アクセス制御の管理など、Bigtable インスタンスに対する完全な制御を付与します。過剰な管理者権限は、データ損失や不正アクセスのリスクを高めます。
Bigtable 管理者ロールを持つプリンシパルの数を制限します。データへの読み取りまたは読み取り/書き込みアクセスのみが必要なアカウントには、bigtable.reader や bigtable.user など、より具体的なロールの使用を検討してください。
デフォルトのネットワークが VPC 構成で使用されているかどうかを確認します。
デフォルトのネットワークは、セキュリティのベスト プラクティスと一致しない可能性のある事前定義された設定を使用して、プロジェクトごとに自動的に作成されます。これには、共通ポートでの受信トラフィックを許可し、事前に設定された IP 範囲を持つ各リージョンにサブネットを作成するデフォルトのファイアウォール ルールが含まれています。
デフォルトのネットワークを使用する代わりに、適切に定義されたサブネットとファイアウォール ルールを使用してカスタム VPC ネットワークを作成します。攻撃対象領域を減らす必要がない場合は、デフォルト ネットワークを削除することを検討してください。
VPC 構成でレガシー ネットワーク ルーティング モードが使用されているかどうかを確認します。
レガシー ネットワーク モードでは、最新の VPC 実装で利用できる高度な機能やセキュリティ制御が欠けている古いルーティング設定が使用されます。レガシー ネットワークは、すべてのリージョンに対して自動的に生成された IPv4 プレフィックスを持つ単一のグローバル ネットワークです。
レガシー ネットワークからリージョン サブネットを備えた VPC ネットワークに移行して、改善されたルーティング機能、より優れたセキュリティ制御、より柔軟な IP アドレス管理を活用します。
DNS ポート (TCP/UDP ポート 53) への無制限のアクセスを許可するファイアウォール ルールをチェックします。
インターネットからの無制限の DNS アクセスを許可するファイアウォール ルールは、DNS 増幅攻撃、データ引き出し、または DNS トンネリングに悪用される可能性があります。このようなオープン アクセスは、攻撃者が内部 DNS 情報をクエリしたり、コマンド アンド コントロール通信に DNS を利用したりする潜在的な経路を提供します。
DNS アクセスを特定の IP 範囲または内部ネットワークに制限します。外部 DNS アクセスが必要な場合は、厳密なフィルタリングとモニタリングを実装して、悪用を検出して防止します。
FTP ポート (TCP ポート 20 および 21) への無制限のアクセスを許可するファイアウォール ルールをチェックします。
FTP は認証情報とデータを平文で送信するため、インターネットからの無制限の FTP アクセスは重大なセキュリティ リスクを引き起こします。これは、資格情報の盗難、不正なデータ アクセス、および潜在的なデータ侵害につながる可能性があります。 FTP には最新の認証機能と暗号化機能もありません。
FTP アクセスを特定の信頼できる IP 範囲に制限するか、SFTP や FTPS などのより安全なファイル転送プロトコルに移行します。ファイル転送サービスに安全にアクセスするには、VPN の実装を検討してください。
インターネットからの無制限の ICMP トラフィックを許可するファイアウォール ルールをチェックします。
無制限の ICMP トラフィックを許可すると、ネットワークが偵察技術、潜在的なサービス拒否攻撃、ICMP トンネリングにさらされる可能性があります。 ICMP はネットワーク診断に正当に使用されますが、インターネットからの無制限のアクセスは通常は不要であり、セキュリティ リスクが増大します。
ICMP トラフィックを特定の信頼できる IP 範囲または内部ネットワークに制限します。特定の目的で外部 ICMP アクセスが必要な場合は、厳格なフィルタリングを実装して、必要な ICMP タイプとコードのみを許可します。
MySQL ポート (TCP ポート 3306) への無制限のアクセスを許可するファイアウォール ルールをチェックします。
MySQL データベース ポートをインターネットに直接公開すると、ブルート フォース攻撃、脆弱性の悪用、不正なデータ アクセスなど、重大なセキュリティ リスクが生じます。データベース サービスは通常、承認されたアプリケーション サーバーから、または安全なチャネルを通じてのみアクセスできるようにする必要があります。
MySQL へのアクセスを特定のアプリケーション サーバーまたは内部ネットワークに制限します。外部アクセス要件には、Cloud SQL プロキシ、プライベート接続、または VPN を使用します。すべてのデータベース接続に強力な認証と暗号化を実装します。
Oracle データベース ポート (TCP ポート 1521) への無制限のアクセスを許可するファイアウォール ルールをチェックします。
Oracle データベースのポートをインターネットに直接公開すると、ブルート フォース攻撃、脆弱性の悪用、不正なデータ アクセスなど、重大なセキュリティ リスクが生じます。データベース サービスは通常、承認されたアプリケーション サーバーから、または安全なチャネルを通じてのみアクセスできるようにする必要があります。
Oracle データベースへのアクセスを特定のアプリケーション サーバーまたは内部ネットワークに制限します。外部アクセス要件にはプライベート接続または VPN を使用します。すべてのデータベース接続に強力な認証と暗号化を実装します。
インターネットからの一般的または非標準のポートへの無制限のアクセスを許可するファイアウォール ルールをチェックします。
インターネットから一般的ではないポートへのアクセスを許可するファイアウォール ルールは、標準以外のポートで実行されているサービス、潜在的なバックドア、またはセキュリティ回避手法を示している可能性があります。これらのポートは、未承認のサービスを実行したり、正規のサービスへの代替アクセスを提供したりするために使用される可能性があります。
一般的ではないポートを確認し、アクセスを制限します。最小限の特権の原則に従って、特定の信頼できるソースからの必要なサービスへのアクセスのみを許可します。サービス ポートの使用法を標準化し、非標準ポートの正当な使用法を文書化します。