このページでは、アーティファクトの保護に役立つ Google Cloud のサービスと機能について説明します。
保存データの暗号化
Google Cloud では、デフォルトで、Google が管理する暗号鍵を使用して、自動的に保存されているデータを暗号化します。データを保護する鍵に関連する具体的なコンプライアンス要件や規制要件がある場合は、顧客管理の暗号鍵（CMEK）で暗号化されたリポジトリを作成できます。
アクセス制御
デフォルトでは、すべてのリポジトリは非公開です。最小権限のセキュリティ原則に従い、ユーザーとサービス アカウントに必要な最小限の権限のみを付与します。
データの引き出しの防止
データの引き出しを防ぐために、VPC Service Controls を使用して、Artifact Registry やその他の Google Cloud サービスをネットワーク セキュリティ境界内に配置できます。
脆弱性スキャン
Artifact Analysis は、一般公開されたパッケージのコンテナ イメージをスキャンしてセキュリティの脆弱性を検出できます。
次のオプションが用意されています。
- 自動脆弱性スキャン
- この機能を有効にすると、コンテナ イメージのパッケージに関する脆弱性が識別されます。イメージが Artifact Registry にアップロードされると、イメージがスキャンされ、イメージを push してから最大 30 日間、新しい脆弱性を検出するためにデータが継続的にモニタリングされます。
- On-Demand Scanning API
- 有効にすると、ローカル イメージ、または Artifact Registry に保存されているイメージを手動でスキャンできます。この機能は、ビルド パイプラインの早い段階で脆弱性を検出して対処するのに役立ちます。たとえば、ビルド後にイメージをスキャンするために Cloud Build を使用し、スキャンによって特定の重大度の脆弱性が検出された場合、Artifact Registry へのアップロードをブロックできます。自動脆弱性スキャンも有効にしている場合は、レジストリにアップロードしたイメージも Artifact Analysis によってスキャンされます。
デプロイ ポリシー
Binary Authorization を使用すると、サポートされている Google Cloud 環境のいずれかにコンテナ イメージをデプロイしようとしたときにサービスによって適用されるポリシーを構成できます。
たとえば、脆弱性スキャン ポリシーを遵守するようにイメージが署名されている場合にのみ、デプロイを許可するように Binary Authorization を構成できます。
未使用イメージの削除
未使用のコンテナ イメージを削除して、ストレージ コストを削減し、古いソフトウェアを使用するリスクを軽減します。gcr-cleaner など、この作業に役立つツールが数多く用意されています。gcr-cleaner ツールは Google の公式プロダクトではありません。
セキュリティのシフトレフト
情報セキュリティ目標を日常業務に統合することで、ソフトウェア デリバリーのパフォーマンスを向上させ、より安全なシステムを構築できます。この考え方は、「シフトレフト」とも呼ばれます。これは、セキュリティに関する問題がソフトウェア開発ライフサイクルの早い段階で対処されることを意味します（左から右のスケジュール図で左側に位置します）。セキュリティのシフトレフトは、DORA State of DevOps 研究プログラムで特定された DevOps 機能の 1 つです。
詳細を確認する方法:
- セキュリティのシフトレフト機能について確認します。
- ホワイトペーパー: セキュリティのシフトレフトをお読みください。これは、ソフトウェア開発ライフサイクル（SDLC）に対する信頼性を高め、セキュリティ リスクの問題を軽減するための責任、プラクティス、プロセス、ツール、テクニックについて説明しています。
公開リポジトリに関する考慮事項
次の場合について注意して検討します。
- 公開ソースからのアーティファクトの使用
- 独自の Artifact Registry リポジトリを公開する
公開ソースからのアーティファクトの使用
アーティファクトの公開ソース（GitHub、Docker Hub、PyPI など）、または npm 一般公開レジストリは、ビルドとデプロイに使用できるツールまたは依存関係を提供します。
ただし、組織によってはパブリック アーティファクトの使用に影響する制約がある場合があります。次に例を示します。
- ソフトウェア サプライ チェーンの内容を制御する場合。
- 外部リポジトリを使用したくない。
- 本番環境で脆弱性を厳密に制御したい。
- すべてのイメージの基本オペレーティング システムを同じにしたい。
ソフトウェア サプライ チェーンを保護する次の方法を検討してください。
- アーティファクトに一貫した既知のコンテンツが含まれるように、自動ビルドを設定します。Cloud Build のビルドトリガーまたは他の継続的インテグレーション ツールを使用できます。
- 標準化されたベースイメージを使用します。Google は、使用可能ないくつかのベースイメージを提供しています。
- アーティファクトの脆弱性に対処します。On-Demand Scanning API を使用して、コンテナ イメージを Artifact Registry に保存する前に脆弱性をスキャンできます。Artifact Analysis は、Artifact Registry に push したコンテナをスキャンすることもできます。
- イメージのデプロイに内部標準を適用します。 Binary Authorization は、サポートされている Google Cloud 環境へのコンテナ イメージのデプロイに適用されます。
公開 Artifact Registry リポジトリ
Artifact Registry リポジトリを公開するには、allUsers ID に Artifact Registry 読み取りロールを付与します。
すべてのユーザーが Google Cloud アカウントを所有している場合は、代わりに allAuthenticatedUsers ID を持つ認証済みユーザーのみにアクセスを制限できます。
Artifact Registry リポジトリを公開する前に、次のガイドラインを検討してください。
- リポジトリに保存するすべてのアーティファクトが一般公開できるもので、認証情報、個人データ、機密データが公開されないことを確認します。
- ユーザーがアーティファクトをダウンロードすると、ネットワーク データ転送に対して課金されます。大量のインターネット ダウンロードのトラフィックが予想される場合は、関連する費用を検討してください。
- デフォルトでは、プロジェクトのユーザーあたりの割り当てに制限はありません。 乱用を防ぐため、プロジェクト内のユーザーあたりの割り当ての上限値を設定します。
ウェブ アプリケーションに関するガイダンス
- OWASP Top 10 には、Open Web Application Security Project（OSOpenSSL）による、上位のウェブ アプリケーションのセキュリティ リスクが一覧表示されています。
コンテナのガイダンス
コンテナ構築のベスト プラクティスには、コンテナ構築に関する推奨事項が含まれます。
イメージのビルドについては、Docker のベスト プラクティスもご覧ください。
コンテナ運用のベスト プラクティスには、アプリケーションを Google Kubernetes Engine とコンテナ全般で実行しやすくする、セキュリティ、モニタリング、ロギングに関する推奨事項が含まれます。
Center for Internet Security（CIS）には、Docker コンテナのセキュリティを評価する Docker ベンチマークがあります。
Docker には、Docker Bench for Security というオープンソース スクリプトがあります。このスクリプトを使用して、実行中の Docker コンテナを CIS Docker ベンチマークに対して検証できます。
Docker Bench for Security は、CIS Docker ベンチマークの多くの項目を確認するのに役立ちますが、スクリプトでは検証できない項目もあります。たとえば、コンテナのホストが強化されているか、コンテナ イメージに個人データが含まれているかどうかは確認できません。ベンチマークのすべての項目を確認し、追加の確認が必要な項目を特定してください。