エビデンス・ロッカーとしての IBM Cloud Object Storage バケットの使用

IBM Cloud Object Storage （COS）バケットを設定することで、 DevSecOps パイプラインに統合されたコンプライアンスチェックによって生成された証拠データを保存することができます。 コンプライアンス・エビデンスは、コンプライアンス監査のときに監査員が探す監査証跡となります。 DevSecOps の目標の 1 つは、エビデンスを生成して監査可能なエビデンス・ロッカーに保管することを自動で行うことです。 詳しくは、 エビデンス・ロッカー を参照してください。

コンプライアンス自動化パイプラインは、COSバケットに以下の情報を保存します：

タスク成果物
テスト結果、スキャン結果、またはタスクによって保存された出力データ。
タスク・ログ
パイプラインの実行が完了すると、その実行に関するログがエビデンスロッカーに送信されます。
エビデンス
タスクに関する情報と、その実行結果（失敗または成功のいずれか）について。 送信されるエビデンスの形式について詳しくは、エビデンスのサマリーを参照してください。

バケットの構成

継続的統合または継続的デプロイメントのツールチェーンをセットアップする前に、専用の Cloud Object Storage インスタンスを作成する必要があります。 この COS バケットは、アプリケーションに対してエビデンス・ロッカーを境界内に作成する必要があるため、コンプライアンス関連のストレージに使用されます。 これにより、パイプラインの回復力が向上します。 詳しくは、 回復力 を参照してください。

継続的インテグレーション（CI）または継続的デプロイメント（CD）パイプラインの一環として、Cloud Object Storage バケットをコンプライアンス証拠保管庫として設定するには、以下の情報を参考にしてください。 パイプラインまたはツールチェーンのテンプレートスクリプトでは、Cloud Object Storage 上のロッカーの設定は行われません。

コンプライアンス・エビデンスにクラウド Object Storage を使用する際の考慮事項（粒度、セキュリティ、...）については、この ページを 参照してください。

保存ポリシー

Cloud Object Storage のバケットでは、アップロードされたオブジェクトに対して保存ポリシーまたは保存期間を適用するように設定できます。これは「 不変オブジェクト（Immutable Object Storage ）」とも呼ばれます。 Immutable Object Storage は、電子レコードを保存してデータの保全性を保ちます。 保存期間ポリシーにより、データは「書き込み1回・読み取り多回（WORM）」方式で、消去および上書きが不可能な状態で保存されます。 保存期間内は保護バケット内のオブジェクトを変更したり削除したりすることはできません。また、保存期間が終了するまでは、オブジェクトが入った保護バケットそのものを削除することもできません。 このポリシーは、保存期間が終了して訴訟ホールドがすべて解除されるまで、適用されます。

チームでエビデンス・ロッカーとして使用するバケットには、すべてのオブジェクトを少なくとも 365 日間保管する保存ポリシーを設定することをお勧めします。

バケットのアクセス許可

DevSecOps 環境内でCloud Pipelinesを使用する場合、証拠、証拠の要約、アーティファクトなどのオブジェクトは、 IBM Cloud Object Storage （COS）内のバケットにパイプで送られたり、そこから読み込まれたりします。 ツールは、オブジェクトやバケットの作成、更新、削除、変更は行いません。

必要なパイプライン操作を円滑に行うと同時に、お客様のクラウドの Object Storage バケットへの安全なアクセスを確保するには、以下のアクセスポリシーに従ってください

  • 読者。

    1. この権限により、 Continuous Delivery （CD）パイプラインはデータを変更することなくバケットの保持設定を検証することができます。
    2. CIパイプラインで生成された証拠を読み込む必要がある

  • オブジェクト・ライター。

    1. この権限により、継続的インテグレーション（CI）、CD、構成管理（CC）パイプラインでバケットに新しいオブジェクトをアップロードしたり、書き込むことが可能になります。

サービス認証情報の作成手順

Cloud Pipelinesを使用してCOSバケットにアクセスするには：

  1. 「サービス認証情報」に移動します
  2. 新しい資格情報を作成する：
    • 「作成」をクリックし、表示される指示に従って、COSバケット用の新しいサービス資格情報を作成します。

COSバケットへのアクセス権限の割り当て手順

COSバケットに適切なアクセス権限を割り当てるには：

  1. IAMバケットの権限に移動します
  2. 役割とポリシーを割り当てる：
    • CDパイプラインにリーダの役割を割り当て、保持ポリシーを確認する。
    • CI、CD、および CC パイプラインにオブジェクトライターのロールを割り当て、バケットにエビデンスを書き込む。

クラウドバケット Object Storage を証拠保管場所として使用する場合、推奨される権限は 「Reader 」と「 Object writer 」です。 オブジェクトの誤操作や悪意のある変更を防ぐため、より高い権限（管理者レベルのアクセスなど）は避けるべきです。

ストレージ・クラス

コストは、それぞれのチームのセットアップやデプロイメントの頻度に応じ、チームごとに異なります。 無料プランのバケットをCloud Object Storage のバケットとして使用することは推奨されません。これは、無料プランではバケットを不変（immutable）に設定できないためです。

見積もりの例

各パイプラインに6つのエビデンスを含むリファレンスの継続的インテグレーション（CI）または継続的デプロイメント（CD）パイプラインを使用している場合、1回のCIおよびCD実行ペアにつき、クラスAのリクエストが37件、クラスBのリクエストが6件発生します。

  • 継続的統合により、6 個のログ、6 個の成果物、および 6 個のエビデンスが書き込まれます。これは 18 個の PUT (クラス A) に相当します。
  • 継続的デプロイでは、6件のエビデンス（6回のGET - クラスB）を読み取り、6件のエビデンス、6件のログ、6件のアーティファクト、および要約を書き込みます。これは、合計19回のPUT - クラスAに相当します。

平均して5つのマイクロサービス（5×継続的インテグレーション）と4つのデプロイメントリージョン（4×継続的デプロイメント）がある場合、1回の完全なデプロイメントは、クラスAのリクエスト166件およびクラスBのリクエスト24件に相当します。

週に 1 回 (毎月 4 回) 完全なデプロイメントを行う場合、1 カ月でクラス A 要求は 664 個、クラス B 要求は 96 個になる計算になります。

収集されるデータ量は、ユース・ケースによって異なります。 エビデンス (1 kB)、テスト成果物 (100 kB)、およびログ (15 kB) の平均サイズを使用して、1 カ月当たりに作成および転送される 0.01 GByte のデータを計算できます。

回復力

境界内に収める必要がある場合は、回復力として Cross-Region か Regional を使用することをお勧めします。 これらのリージョンについて詳しくは、エンドポイントおよびストレージ・ロケーションを参照してください。

バケット名

Cloud Object Storage のバケット名は、グローバルに一意であり、DNS に準拠している必要があります。 名前は長さが 3 から 63 文字で、小文字、数字、およびダッシュが含まれている必要があります。 バケット名の先頭と末尾は、小文字か数値でなければなりません。 IP アドレスに似た名前は使用できません。 バケット名は、IBM Cloud Object Storage システム全体で固有でなければならず、名前や住所の一部、金融/証券口座、社会保障番号などの個人情報を含めることはできません。

パブリック・クラウド内のすべてのバケットが 1 つのグローバル名前空間を共有するため、バケット名は固有である必要があります。 この要件により、サービスインスタンスやアカウント情報を一切指定することなく、バケットにアクセスすることが可能になります。 また、 cosv1- や アカウント で始まる名前のバケットを作成することもできません。これらの接頭辞はシステムによって予約されているためです。

エンドポイント

IBM Cloud® 内から発生するほとんどの要求には private エンドポイントを使用し、 IBM Cloud®外部から発生するほとんどの要求には public エンドポイントを使用します。 詳しくは、エンドポイント・タイプ を参照してください。

ロンドン地域で実行されているパイプラインの場合は、パイプライン管理のワーカー・インフラストラクチャーがあるため、 direct エンドポイントを使用します。

COSバケットを使用したツールチェーンの設定

証拠、資産、添付ファイルを保存するには、パイプラインにCOSバケットを設定します。 このバケットは既存の情報を取得するために使用されるため、 Reader および Object Writer のアクセス権限が必要です。 このバケットをパイプラインに設定します。

COSバケット構成の環境プロパティ |名前 |タイプ |説明 |必須またはオプション |ロックまたはアンロック |:----------|:------------------------------|:------------------|:----------|:----------| | cos-api-key | SECRET | Cloud Object Storage APIキー。 | 必須 | Locked | | cos-access-key-id | SECRET | Cloud Object Storage HMAC 認証のアクセスキーID。 （ cos-api-key の代わりに cos-secret-access-key とともに提供）| 必須 | ロック解除済み | | cos-secret-access-key | SECRET | HMAC 認証の Cloud Object Storage シークレットアクセスキー。 （ cos-api-key の代わりに cos-access-key-id とともに提供）| 必須 | ロック解除済み | | cos-bucket-name | テキスト | Cloud Object Storage インスタンス内で、証拠保管庫として使用されるバケットの名前。 | 必須 | ロック解除済み | cos-endpoint テキスト Cloud Object Storage インスタンスから証拠を読み取るエンドポイント。このインスタンスは証拠保管庫として使用されます。 詳細については 、「エンドポイントの種類」 を参照してください。 必須 ロック解除済み

すべてのパイプライン CI/CD/CC で同じバケットを設定します。

エビデンスロッカー Git からCOSエビデンスロッカーへの移行

ビルドのパフォーマンス、信頼性、スケーラビリティを向上させるため、-based Git Evidence Lockers のサポートは非推奨となりました。 (COS)ベース Cloud Object Storage のエビデンスロッカーへの移行により、運用 Git への依存度を低減し、プロバイダー Git hosting からのレート制限問題を回避できます。

すべてのユーザーは、COS証拠保管庫を使用するためにツールチェーンとパイプラインを更新する必要があります。

ツールチェーンが証拠保管 Git 庫のみを使用する場合

移行を完了するには、以下の手順に従ってください：

ツールチェーンが と COS Git Evidence Lockers の両方を使用する場合

両方が既に設定されている場合：

  • すべてのパイプラインから環境 evidence-repo プロパティを削除してください。
  • ツールチェーン内の証拠リポジトリに関連付けられた統合 GitHub/GitLab を削除してください。

CDパイプラインの移行準備：からCOS証拠 Git 保管庫へ

CIおよびCDパイプラインがEvidence Git Lockerに依存している場合、CDパイプラインはCOS Evidence Lockerを使用するようにブートストラップする必要があります。 以下の方法の中から1つを選んでください。

アプローチ1：両方のエビデンスロッカーを用いたブートストラップ

このアプローチでは、 Git エビデンスロッカーの設定が維持されたまま、COSエビデンスロッカーが有効化されます。 両方を並行して実行することで、Evidence Git Locker を使用して COS Evidence Locker を自動的にブートストラップできます。

  • 証拠保管 Git 庫の設定を維持する。
  • COS証拠保管庫を有効にする。
  • (推奨: v10.45.0 ) より前のバージョンのパイプライン定義 v10.46.1 を使用してCDパイプラインを実行してください。
  • 実行が完了したら、前述の手順に従って証拠保管庫の設定 Git を削除してください。

アプローチ2： Git エビデンスロッカーなしのブートストラップ

クリーンな移行を優先し、依存せずに済む場合はこのアプローチ Git を使用してください。

  • 証拠保管庫の設定 Git を削除してください。
  • パラメータ force-redeploy を に設定した true 状態で、CDパイプラインを1回実行する。
  • 実行が完了したら、パラメータを に force-redeploy リセット false するか、完全に削除してください。

この1回限りのCDパイプライン実行により、COS証拠保管庫に既存の全在庫資産が確実に登録されます。 最初の実行は一度だけ必要であり、その後は実行する必要はありません。 実際のデプロイを実行したくない場合は、デプロイおよび受け入れテストの段階をスキップし、デプロイ操作を一切行わずにCDパイプラインを実行できます。

証拠 Git 保管庫は、削除後にアーカイブすることを選択できます。監査目的で必要となるためです。

あるCOSバケットから別のCOSバケットへの移行

One COS Bucketから別のCOS Bucketへの移行 すでにCOSの証拠品ロッカーをご利用のお客様で、One COS Bucketから別のCOS Bucketへの移行が必要な場合は、ワークフローを中断することなくスムーズに移行することが重要です。 以下は、COSバケット間の移行手順と考慮事項です。

移行の理由：

  • 組織再編 ：あるCOSバケットの使用を停止し、別のバケットの使用を開始したい場合があるかもしれません。
  • バケットの移行 ：組織変更やコンプライアンス要件により、バケットを1つのアカウントから別のものに移行する必要がある。

移行手順：

バックアップ-COSバケットの設定 ：古いCOSバケットから新しいバケットにマイグレーションする場合は、パイプラインが古いバケットと新しいバケットの両方を使用するように設定されていることを確認してください。 これにより、既存のワークフローを中断することなく、スムーズな移行が可能になります。

  • 上記の手順に従って、新しいCOSバケットを作成します。
  • IAMポリシーの設定：新しいCOSバケットに、パイプラインで必要とされるReaderおよびObject Writerアクセス用の必要なIAMポリシーが設定されていることを確認してください。
  • 環境変数の更新

IBM ツールチェーンでは、環境変数を更新して、古いCOSバケットと新しいCOSバケットの両方を含めます。 古いバケットを設定するには、すべてのCOS環境プロパティでbackup-接頭辞を使用し、新しいCOSバケットを設定するには通常のプロパティを使用します。

名前 タイプ 説明 必須またはオプションです ロックされている、またはロックされていない
backup-cos-api-key シークレット Cloud Object Storage のバックアップAPIキー。 必須 ロック済み
backup-cos-access-key-id シークレット バックアップ Cloud Object Storage HMAC 認証情報からのアクセスキーID。 （ backup-cos-api-key の代わりに backup-cos-secret-access-key とともに提供） 必須 ロック解除
backup-cos-secret-access-key シークレット HMAC 認証からバックアップ Cloud Object Storage シークレットアクセスキーを取得します。 （ backup-cos-api-key の代わりに backup-cos-access-key-id とともに提供） 必須 ロック解除
backup-cos-bucket-name テキスト Cloud Object Storage インスタンス内で、証拠保管庫として使用されるバックアップバケットの名前。 必須 ロック解除
backup-cos-endpoint テキスト エビデンスを読み取るエンドポイント。 Cloud Object Storage インスタンスは、エビデンスロッカーとして使用されます。 詳細については 、「エンドポイントの種類」 を参照してください。 必須 ロック解除

古いバケツは監査上必要なので、365日間は削除しないでください。

低速で実行されるパイプラインのトラブルシューティングガイド

  1. force-redeploy 全エントリーの再デプロイでない限り、trueに設定すべきではない。
  2. プロモーション・パイプラインは、デルタ計算が正しく行われるように、正しいデルタのセットをプロモートするために使用されるべきである。
  3. このような行が表示される場合は、CIパイプラインが正しいサマリーを生成していないことを意味する。 CIパイプラインに戻り、ミニサマリーの作成中にエラーが発生していないか確認して、ステップを終了する。