Continuous Delivery でのデータの保護
DevOps Insights 2026年8月31 日にサービス終了となり、提供が中止されます。 Continuous Delivery は、2027年2月12日に以下のリージョンで提供が中止されます: au-syd、 ca-tor、 us-east。 また、同日をもって、Code Risk Analyzerもすべての地域で提供を終了いたします。 あるリージョンでこれらの機能が実際に利用されていない場合、そのリージョンにおける機能は早期に提供終了となり、新しいインスタンスの受け入れが停止される可能性があります。 詳細はこちら
IBM Cloud® Continuous Delivery は、可用性の高い安全な環境でデータベースをホストします。
- データの暗号化は、Continuous Delivery サービスの内部にある暗号鍵、またはそのサービスが依存するサービスとインフラストラクチャーを使用して、保存時 (GPFS、LUKS、組み込みディスク) にも、転送中 (HTTPS、SSH) にも行われます。
- 個人データの暗号化は、Professionalプランでのみ可能です IBM® Key Protect for IBM Cloud® サービスまたは サービスのインスタンス内でルートキーを使用することで。 IBM Cloud® Hyper Protect Crypto Services
- クライアント資格情報とシステム資格情報は、暗号化ディスクに保管されます。
- ツール統合の構成データと Delivery Pipeline プロパティー値には、機密情報が含まれている場合があります。 このデータは、サービス内部のデータベースに保管されているため、Continuous Delivery サービス内部の暗号鍵を使用して暗号化されます。
- アプリケーションとデータは、高可用性に対応するように構成されます。
- データへのアクセスは、サービスのサポートと維持のためにデータを必要とするユーザーのみに限定されます。
Continuous Delivery での機密データの保護
Continuous Delivery サービスは、サービスが内部で使用するデータベースに顧客所有の機密データが保存される前に、それらを暗号化します。 機密データには、サード・パーティー・ツールの統合構成データと Delivery Pipeline プロパティー値が含まれます。 データは、 Continuous Delivery サービス内部の暗号化キー、または IBM® Key Protect for IBM Cloud® サービスもしくは IBM Cloud® Hyper Protect Crypto Services サービスのインスタンス内で指定されたルートキーに基づく暗号化キーを使用して暗号化されます。
DevOps プロセスでは、アプリケーションをビルド、テスト、デプロイするときに他のシステムと対話するために、さまざまな資格情報 (ユーザー名とパスワード、API キー、サービス・キー、SSH キーなど) が必要になることがよくあります。 お客様は、そのような資格情報が意図した対象者以外に誤って知られることがないようにする必要があります。 このような資格情報が悪意のある人物によってアクセスされると、IT 運用が中断されたり、予期しないコストが生じたり、お客様のリソースが攻撃に利用されたりする可能性があります。 IBM には、お客様の資格情報のセキュリティーを保護および保守する責任はありません。
資格情報を保護するには、以下のガイダンスに従う必要があります。
- Git リポジトリーに資格情報を保管しないでください。 リポジトリーの設定によっては、リポジトリー内のファイルを組織内の他のメンバーや、他の IBM Cloud ユーザー、または公衆のインターネットで表示できることがあります。
- ユーザー資格情報を Delivery Pipeline 定義に含めないでください。他のユーザーが表示できる可能性があるためです。 特に、ユーザー資格情報を Delivery Pipeline の Classic ジョブの定義スクリプト、Delivery Pipeline の Tekton の yaml ファイル、またはデリバリー・パイプラインで開始されるスクリプト内に入力しないでください。
- パイプラインの実行時に生成されるログ・ファイルにユーザー資格情報が出力されないようにしてください。ログ・ファイルは共有されることがあります。
- ツール統合、 Tekton パイプライン環境プロパティー、または Tekton パイプライン・トリガー・プロパティーを構成する場合など、 Continuous Delivery API の呼び出しでは、資格情報をプレーン・テキストで指定しないでください。
- POST /toolchains/{toolchain_id}/events API の呼び出しに、資格情報、個人識別情報、またはその他の機密情報を含めないでください。 この API は、指定されたデータを含むイベントを、ツールチェーンに統合された Event Notifications のインスタンスに送信します。 その後、 Event Notifications は、E メール、SMS、Slack などの構成済みの宛先にイベントを転送します。
- ツール統合リソース、Tekton パイプライン環境プロパティー・リソース、または Tekton パイプライン・トリガー・プロパティー・リソースを定義する場合など、Terraform 構成ファイルでは資格情報をプレーン・テキストで指定しないでください。 代わりに、秘密ストレージ・サービスで資格情報を管理し、API 呼び出しおよび Terraform 構成で参照によって資格情報を指定します。 参照によるシークレットの管理について詳しくは、 シークレット参照を使用した資格情報の保護 を参照してください。
IBM Cloud には、セキュアな鍵の保管とシークレットに使用できるいくつかのオプションが用意されています。
- の Classic パイプラインのセキュア環境のプロパティー
- Tekton パイプラインのセキュア環境のプロパティー
- IBM® Key Protect for IBM Cloud®
- IBM Cloud® Hyper Protect Crypto Services
- HashiCorp Vault
セキュアな DevOps ベスト・プラクティスについて詳しくは、 DevOps Securityを参照してください。
シークレット参照を使用した資格情報の保護
Continuous Delivery ツールチェーンおよびデリバリー・パイプライン (パスワード、API 鍵、証明書、その他のトークンなど) で作業する場合に構成できるプロパティーの多くは、シークレットまたは資格情報として分類されます。 セキュア・プロパティーの値を設定するには、プレーン・テキストまたは秘密参照のいずれかを使用できます。 セキュア・プロパティーの値を設定する場合は、シークレット参照を使用することをお勧めします。
プレーン・テキスト の秘密値を使用してセキュア・プロパティーを設定すると、 Continuous Delivery はアクティブに値を暗号化し、内部に保管します。 値は Continuous Delivery サービス内で保護されていますが、サービスはクライアント・サイドの値を保護できません。 ブラウザーでコンソールを使用するか、API を呼び出すか、または Terraform リソースを構成することによって、セキュア・プロパティーを設定すると、ローカル・システムでプレーン・テキストの秘密が公開される可能性があります。 プレーン・テキストのシークレットをローテートすることも難しくなります。 API キーなどのシークレットをローテートする必要がある場合は、シークレット値を持つすべてのセキュア・プロパティーも見つけて更新する必要があります。
セキュア・プロパティに secrets参照値を設定する場合、その値は特別にフォーマットされた文字列となります。 IBM® Key Protect for IBM Cloud®, IBM Cloud® Secrets Manager や HashiCorp Vault などの秘密保存サービス内で管理されている秘密の場所やアドレスを指す特別な形式の文字列です。 Continuous Delivery は、シークレット参照値をアクティブに暗号化して内部に保管しますが、シークレット値はクライアント・サイドで公開されません。 Continuous Delivery は、ユーザーに代わって処理を実行するためにシークレットを取得する必要がある場合、参照されているシークレット・ストアから値を内部的に取得します。 シークレットの参照もローテーションに対して回復力があります。 通常、シークレットがシークレット・ストア内でローテートされる場合、シークレットの場所またはアドレスは同じままです。 シークレット値自体のみが変更されます。
2 つのタイプの秘密参照 (名前または クラウド・リソース名(CRN)) がサポートされています。 現在、CRN によるシークレットの参照をサポートしているのは、 Secrets Manager ツール統合のみです。 正しい 許可 が設定されている場合は、別のアカウントの Secrets Manager インスタンスからシークレットを参照できるため、このフォーマットにより柔軟性が向上します。
ツールチェーンの有効範囲内でシークレット参照を指定するには、以下の前提条件を必ず考慮してください。
- シークレット・ストアは、ツール統合としてツールチェーンに追加する必要があります。 シークレットストアのツール統合の詳細については、 設定 Key Protect、 設定 Secrets Manager、 設定 HashiCorp Vault を参照。
- ソース・ツールチェーンがターゲット・シークレット・ストアからシークレットを取得できるように、IAM サービス間許可ポリシーを構成する必要があります。 サービス間許可について詳しくは、 サービス間のアクセス権限を付与するための許可の使用 を参照してください。
API や Terraform など、コンソールの外部で作業する場合は、名前によるシークレット参照に以下の形式を使用します。
{vault::SECRET_STORE_INTEGRATION_NAME.SECRET_NAME}( Key Protect内に含まれているシークレットを参照する場合)。{vault::SECRET_STORE_INTEGRATION_NAME.SECRET_GROUP_NAME.SECRET_NAME}( Secrets Manager内に含まれているシークレットを参照する場合)。{vault::SECRET_STORE_INTEGRATION_NAME.SECRET_NAME.FIELD_NAME}HashiCorp Vault に含まれる秘密を参照する場合。
秘密の価値:
ref://secrets-manager.REGION.RESOURCE-GROUP.SECRETS-MANAGER-INSTANCE-NAME1/SECRETS-GROUP-NAME/SECRET-NAME( Key Protect内に含まれているシークレットを参照する場合)。ref://secrets-manager.eu-de.EU-RG.SM-1/default/api-key( Secrets Manager内に含まれているシークレットを参照する場合)。
例えば、シークレットがキーの値であれば、キーを選択することができる:
ref://secrets-manager.eu-gb.Default.Secrets%20Manager-zc/Default/mk-kv-pair?key=ibmcloud-api-key
ここで、
SECRETS-MANAGER-INSTANCE-NAME1は、シークレット・ストア・サービス・インスタンスの名前では なく 、ツールチェーン内のシークレット・ストア統合の名前です。SECRET_GROUP_NAMEは、 Secrets Manager内のシークレットを含むグループの名前です。SECRET_NAMEは、シークレットストア内のシークレットの名前です。KEY_NAMEはキーと値の秘密のキーの名前である。
CRN 秘密参照を使用するには、 Secrets Manager UI から直接、または CLI、API、または SDK を使用してプログラマチックに、秘密 CRN を取得します。
コンソールを使用した秘密参照の指定
コンソールを使用する場合、ツール統合構成プロパティーのフィールドと、セキュアとして分類されている Delivery Pipeline プロパティーには、鍵アイコンのアノテーションが付けられます。 このアイコンをクリックすると、シークレット・ストアとシークレットを選択できるダイアログが開きます。 あるいは、CRN による秘密参照の場合は、CRN 値をプロパティーに直接貼り付けます。
API を使用した秘密参照の指定
IAM ベアラー・トークンを必要とする API の呼び出しで、シークレット参照値を使用してセキュア・プロパティーを処理できます。 あるいは、SDK を使用している場合は、 IAM API キーを取得 し、環境変数を使用してクライアント・オプションを設定します。
export CD_TOOLCHAIN_AUTH_TYPE=iam && \
export CD_TOOLCHAIN_APIKEY={iam_api_key} && \
export CD_TOOLCHAIN_URL=https://api.us-south.devops.cloud.ibm.com/toolchain/v2
名前によるシークレット参照の使用
以下の例は、名前シークレットによるシークレット参照を使用する方法を示しています。 Key Protectのインスタンスに保管されている API トークン (Slack Webhook) を使用して Slack ツール統合を作成する方法を示します。 この例では、ツールチェーンに Key Protect ツール統合が既に含まれており、ソース・ツールチェーンからターゲット Key Protect サービス・インスタンスへの IAM サービス間許可ポリシーが配置されていることを想定しています。
curl -X POST \
https://api.us-south.devops.cloud.ibm.com/toolchain/v2/toolchains/01234567-89ab-cdef-0123-456789abcdef/tools \
-H "Authorization: Bearer $TOKEN" \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
"tool_type_id": "slack",
"parameters": {
"api_token": "{vault::my-kms-tool-integration.my-slack-webhook}",
"channel_name": "my_slack_channel_name",
"team_url": "my_slack_team_name"
}
}'
const CdToolchainV2 = require('@ibm-cloud/continuous-delivery/cd-toolchain/v2');
...
(async () => {
const toolchainService = CdToolchainV2.newInstance();
const slackParameters = {
api_token: "{vault::my-kms-tool-integration.my-slack-webhook}",
channel_name: "my_slack_channel_name",
team_url: "my_slack_team_name"
};
const toolPrototypeModel = {
toolchainId: "01234567-89ab-cdef-0123-456789abcdef",
toolTypeId: "slack",
parameters: slackParameters
};
const slackTool = await toolchainService.createTool(toolPrototypeModel);
})();
import (
"github.com/IBM/continuous-delivery-go-sdk/cdtoolchainv2"
)
...
toolchainClientOptions := &cdtoolchainv2.CdToolchainV2Options{}
toolchainClient, err := cdtoolchainv2.NewCdToolchainV2UsingExternalConfig(toolchainClientOptions)
slackParameters := map[string]interface{}{
"api_token": "{vault::my-kms-tool-integration.my-slack-webhook}",
"channel_name": "my_slack_channel_name",
"team_url": "my_slack_team_name",
}
createToolOptions := toolchainClient.NewCreateToolOptions("01234567-89ab-cdef-0123-456789abcdef", "slack")
createToolOptions.SetParameters(slackParameters)
slackTool, response, err := toolchainClient.CreateTool(createToolOptions)
from ibm_continuous_delivery.cd_toolchain_v2 import CdToolchainV2
...
toolchain_service = CdToolchainV2.new_instance()
slack_parameters = {
"api_token": "{vault::my-kms-tool-integration.my-slack-webhook}",
"channel_name": "my_slack_channel_name",
"team_url": "my_slack_team_name"
}
slack_tool = toolchain_service.create_tool(
toolchain_id = "01234567-89ab-cdef-0123-456789abcdef",
tool_type_id = "slack",
parameters = slack_parameters
)
import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.CdToolchain;
import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.model.*;
...
CdToolchain toolchainService = CdToolchain.newInstance();
HashMap<String, Object> slackParameters = new HashMap<>();
slackParameters.put("api_token", "{vault::my-kms-tool-integration.my-slack-webhook}");
slackParameters.put("channel_name", "my_slack_channel_name");
slackParameters.put("team_url", "my_slack_team_name");
CreateToolOptions createSlackToolOptions = new CreateToolOptions.Builder()
.parameters(slackParameters)
.toolchainId({toolchain_id})
.toolTypeId("slack")
.build();
Response<ToolchainToolPost> response = toolchainService.createTool(createSlackToolOptions).execute();
ToolchainToolPost slackTool = response.getResult();
以下の表に、前の例で使用されている各シークレット参照値をリストして説明します。
| 値 | 説明 |
|---|---|
my-kms-tool-integration |
ツールチェーン内の Key Protect ツール統合の名前です。 Key Protect サービス・インスタンスの名前ではありません。 |
my-slack-webhook |
Key Protect サービス・インスタンス内で管理される標準鍵の名前。 |
CRN による秘密参照の使用
以下の例は、CRN シークレットによるシークレット参照を使用する方法を示しています。 Secrets Managerのインスタンスに保管されている API トークン (Slack Webhook) を使用して Slack ツール統合を作成する方法を示します。 この例では、ツールチェーンに Secrets Manager ツール統合が既に含まれており、ソース・ツールチェーンからターゲット Secrets Manager サービス・インスタンスへの IAM サービス間許可ポリシーがあることを想定しています。
curl -X POST \
https://api.us-south.devops.cloud.ibm.com/toolchain/v2/toolchains/01234567-89ab-cdef-0123-456789abcdef/tools \
-H "Authorization: Bearer $TOKEN" \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
"tool_type_id": "slack",
"parameters": {
"api_token": "crn:v1:bluemix:public:secrets-manager:us-south:a/9bb43e401a7a87d15145da761da98571:604de62c-c04f-3f5e-b7e8-4acafe0ecde7:secret:5ec17023-b631-fbcb-ef9c-4f2eb01f1dda",
"channel_name": "my_slack_channel_name",
"team_url": "my_slack_team_name"
}
}'
const CdToolchainV2 = require('@ibm-cloud/continuous-delivery/cd-toolchain/v2');
...
(async () => {
const toolchainService = CdToolchainV2.newInstance();
const slackParameters = {
api_token: "crn:v1:bluemix:public:secrets-manager:us-south:a/9bb43e401a7a87d15145da761da98571:604de62c-c04f-3f5e-b7e8-4acafe0ecde7:secret:5ec17023-b631-fbcb-ef9c-4f2eb01f1dda",
channel_name: "my_slack_channel_name",
team_url: "my_slack_team_name"
};
const toolPrototypeModel = {
toolchainId: "01234567-89ab-cdef-0123-456789abcdef",
toolTypeId: "slack",
parameters: slackParameters
};
const slackTool = await toolchainService.createTool(toolPrototypeModel);
})();
import (
"github.com/IBM/continuous-delivery-go-sdk/cdtoolchainv2"
)
...
toolchainClientOptions := &cdtoolchainv2.CdToolchainV2Options{}
toolchainClient, err := cdtoolchainv2.NewCdToolchainV2UsingExternalConfig(toolchainClientOptions)
slackParameters := map[string]interface{}{
"api_token": "crn:v1:bluemix:public:secrets-manager:us-south:a/9bb43e401a7a87d15145da761da98571:604de62c-c04f-3f5e-b7e8-4acafe0ecde7:secret:5ec17023-b631-fbcb-ef9c-4f2eb01f1dda",
"channel_name": "my_slack_channel_name",
"team_url": "my_slack_team_name",
}
createToolOptions := toolchainClient.NewCreateToolOptions("01234567-89ab-cdef-0123-456789abcdef", "slack")
createToolOptions.SetParameters(slackParameters)
slackTool, response, err := toolchainClient.CreateTool(createToolOptions)
from ibm_continuous_delivery.cd_toolchain_v2 import CdToolchainV2
...
toolchain_service = CdToolchainV2.new_instance()
slack_parameters = {
"api_token": "crn:v1:bluemix:public:secrets-manager:us-south:a/9bb43e401a7a87d15145da761da98571:604de62c-c04f-3f5e-b7e8-4acafe0ecde7:secret:5ec17023-b631-fbcb-ef9c-4f2eb01f1dda",
"channel_name": "my_slack_channel_name",
"team_url": "my_slack_team_name"
}
slack_tool = toolchain_service.create_tool(
toolchain_id = "01234567-89ab-cdef-0123-456789abcdef",
tool_type_id = "slack",
parameters = slack_parameters
)
import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.CdToolchain;
import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.model.*;
...
CdToolchain toolchainService = CdToolchain.newInstance();
HashMap<String, Object> slackParameters = new HashMap<>();
slackParameters.put("api_token", "crn:v1:bluemix:public:secrets-manager:us-south:a/9bb43e401a7a87d15145da761da98571:604de62c-c04f-3f5e-b7e8-4acafe0ecde7:secret:5ec17023-b631-fbcb-ef9c-4f2eb01f1dda");
slackParameters.put("channel_name", "my_slack_channel_name");
slackParameters.put("team_url", "my_slack_team_name");
CreateToolOptions createSlackToolOptions = new CreateToolOptions.Builder()
.parameters(slackParameters)
.toolchainId({toolchain_id})
.toolTypeId("slack")
.build();
Response<ToolchainToolPost> response = toolchainService.createTool(createSlackToolOptions).execute();
ToolchainToolPost slackTool = response.getResult();
Terraform を使用した秘密参照の指定
Terraform のシークレット参照値を使用して、セキュア・プロパティーを操作できます。
名前によるシークレット参照の使用
以下の例は、 Key Protect サービス・インスタンス、標準キー (Slack Webhook)、ツールチェーン、IAM サービス間許可ポリシー、 Key Protect ツール統合、および Web フック・シークレットを名前で参照する Slack ツール統合のための完全なリソース・セットを示しています。
この例には、Slack Webhook base64-encoded シークレットに設定された標準 ibm_kms_key キー payload リソースも含まれています。 これは、キーの名前と、Slack ツール統合リソース内の秘密参照の値との間の関係を示します。 実際には、事前に別個の Terraform プロジェクトから、または権限のある限られた担当者のみがアクセスできるその他のプロセスから標準鍵を作成する方が、より安全です。
variable "slack_webhook" {}
variable "slack_channel" {}
variable "slack_team" {}
data "ibm_resource_group" "rg" {
name = "default"
}
resource "ibm_resource_instance" "kms" {
name = "my-kms-service-instance"
service = "kms"
plan = "tiered-pricing"
location = "us-south"
resource_group_id = data.ibm_resource_group.rg.id
}
resource "ibm_kms_key" "key" {
instance_id = ibm_resource_instance.kms.guid
key_name = "my-slack-webhook"
standard_key = true
payload = base64encode(var.slack_webhook)
}
resource "ibm_cd_toolchain" "toolchain" {
name = "tf-toolchain-secret-refs"
resource_group_id = data.ibm_resource_group.rg.id
}
resource "ibm_iam_authorization_policy" "s2s" {
source_service_name = "toolchain"
source_resource_instance_id = ibm_cd_toolchain.toolchain.id
target_service_name = "kms"
target_resource_instance_id = ibm_resource_instance.kms.guid
roles = ["Viewer", "ReaderPlus"]
}
resource "ibm_cd_toolchain_tool_keyprotect" "integration" {
toolchain_id = ibm_cd_toolchain.toolchain.id
parameters {
name = "my-kms-tool-integration"
region = var.region
resource_group = data.ibm_resource_group.rg.name
instance_name = ibm_resource_instance.kms.name
}
depends_on = [
ibm_iam_authorization_policy.s2s
]
}
resource "ibm_cd_toolchain_tool_slack" "integration" {
toolchain_id = ibm_cd_toolchain.toolchain.id
parameters {
webhook = "{vault::my-kms-tool-integration.my-slack-webhook}"
channel_name = var.slack_channel
team_name = var.slack_team
}
depends_on = [
ibm_cd_toolchain_tool_keyprotect.integration
ibm_kms_key.key
]
}
以下の表に、前の例で使用されている各シークレット参照値をリストして説明します。
| 値 | 説明 |
|---|---|
my-kms-tool-integration |
ツールチェーン内の Key Protect ツール統合の名前です。 Key Protect サービス・インスタンスの名前ではありません。 |
my-slack-webhook |
Key Protect サービス・インスタンス内で管理される標準鍵の名前。 |
CRN による秘密参照の使用
以下の例では、 Secrets Manager のインスタンスが存在することを前提としています。 任意のシークレット (Slack Webhook)、ツールチェーン、IAM サービス間許可ポリシー、 Secrets Manager ツール統合、および CRN によって Webhook シークレットを参照する Slack ツール統合のリソースが表示されます。
この例には、 payload が Slack Webhook 秘密に設定されている ibm_sm_arbitrary_secret キー・リソースが含まれています。 これは、Slack ツール統合リソース内の秘密参照の値として、キー・リソースから CRN を使用する方法を示しています。 実際には、事前に別個の Terraform プロジェクトから、または権限のある限られた担当者のみがアクセスできるその他のプロセスから標準鍵を作成する方が、より安全です。
variable "slack_webhook" {}
variable "slack_channel" {}
variable "slack_team" {}
variable "secrets_manager_name" {}
data "ibm_resource_group" "rg" {
name = "default"
}
data ibm_resource_instance "sm" {
name = var.secrets_manager_name
}
resource "ibm_sm_arbitrary_secret" "key" {
instance_id = data.ibm_resource_instance.sm.guid
region = data.ibm_resource_instance.sm.location
secret_group_id = "default"
name = "my-slack-webhook"
payload = "var.slack_webhook"
}
resource "ibm_cd_toolchain" "toolchain" {
name = "tf-toolchain-secret-refs"
resource_group_id = data.ibm_resource_group.rg.id
}
resource "ibm_iam_authorization_policy" "s2s" {
source_service_name = "toolchain"
source_resource_instance_id = ibm_cd_toolchain.toolchain.id
target_service_name = "secrets-manager"
target_resource_instance_id = data.ibm_resource_instance.sm.guid
roles = ["Viewer", "SecretsReader"]
}
resource "ibm_cd_toolchain_tool_secretsmanager" "integration" {
toolchain_id = ibm_cd_toolchain.toolchain.id
parameters {
name = "my-sm-tool-integration"
instance_id_type = "instance-crn"
instance_crn = data.ibm_resource_instance.sm.resource_crn
}
depends_on = [
ibm_iam_authorization_policy.s2s
]
}
resource "ibm_cd_toolchain_tool_slack" "integration" {
toolchain_id = ibm_cd_toolchain.toolchain.id
parameters {
webhook = ibm_sm_arbitrary_secret.key.crn
channel_name = var.slack_channel
team_name = var.slack_team
}
depends_on = [
ibm_cd_toolchain_tool_secretsmanager.integration
]
}
お客様管理の鍵によるデータの保護
デフォルトでは、 Continuous Delivery は、 Continuous Delivery サービスの内部にある鍵を使用してデータを暗号化します。 セキュリティーと制御を強化するために、管理対象の鍵を使用してデータを暗号化するように Continuous Delivery を構成できます。 このオプションは、プロフェッショナル・プランの下でのみ、かつ Continuous Delivery サービスのインスタンスをプロビジョニングする時点でのみ使用可能です。 Key Protect や IBM Cloud® Hyper Protect Crypto Services などの独自のキー管理サービスを選択した場合、以下の値は、 Continuous Delivery サービス内部の暗号化キーではなく、独自のキーを使用して暗号化されます。
| コンポーネント | 値 |
|---|---|
| ツール・チェーン | プロパティーおよびパラメーター |
| パイプライン | * プロパティーのキーと値 * ジョブ・ログ * ジョブ成果物 |
| 統合 | * Slack(Slack Webhook) * Pagerduty(API アクセスキー、統合キー) * Sauce Labs(アクセスキー) * Artifactory (API キー) * HashiCorp Vault (トークン、ロール ID、シークレット ID、パスワード) * Jenkins ( Jenkins API トークン) * JIRA (JIRA APIトークン) * Nexus (認証トークン) * Rational Team Concert (パスワード) * Sonarqube ( SonarQube のパスワードまたは認証トークン) |
| IBM Cloud® DevOps Insights | テスト・レコード内の添付ファイル |
以下のコンポーネントは、プロバイダー管理の暗号鍵のみを使用して個人データを暗号化します。
| コンポーネント | 値 |
|---|---|
| Git Repos and Issue Tracking |
|
カスタマー・キーを使用してデータを暗号化する Continuous Delivery サービス・インスタンスの作成について詳しくは、 Continuous Delivery サービス・インスタンスの作成 を参照してください。
サード・パーティー・ツール統合を使用する場合のデータの保護
ツールチェーンのツール統合を構成するときに、Continuous Delivery サービスとツール統合の間のデータ共有を明示的に有効にします。 共有されるデータの種類や、データがツールに送信されるか、ツールから受信されるか、またはその両方かは、ツール統合のタイプによって異なります。
ツール統合を構成する前に、共有されるデータを理解しておく必要があります。 規制対象データまたは機密と見なすデータを処理する場合は、サード・パーティー・ツールの使用および共有される可能性があるすべてのデータが、リソースの機密性、保全性、可用性を損なわないこと、またはその他の規制管理に違反しないことを確認する必要があります。
ツール統合について詳しくは、ツール統合の構成を参照してください。
Git Repos and Issue Tracking を使用する場合のデータの保護
Git Repos and Issue Tracking は、IBM がホストする Continuous Delivery サービスのコンポーネントです。 ソース・ファイル、問題、プル要求、およびプロジェクト構成プロパティーなど、Git Repos and Issue Tracking に提供するすべてのデータは、Continuous Delivery 内で安全に管理されます。 ただし、Git Repos and Issue Tracking は、ユーザーおよびサード・パーティーにデータをエクスポート、送信、またはその他の方法で共有するためのさまざまなメカニズムをサポートしています。
Git Repos and Issue Tracking の情報共有機能は、多くのソーシャル・コーディング・プラットフォームの標準的な機能です。 ただし、このような情報の共有は、貴社の事業に適用される規制上の規制と抵触する可能性があります。 Git Repos and Issue Tracking でプロジェクトを作成した後、ファイル、問題、レコード、またはその他のデータをプロジェクトに委託する前に、プロジェクト設定を確認し、データを保護するために必要な設定を変更します。 確認する設定は、可視性レベル、E メール通知、統合、Web フック、アクセス・トークン、デプロイ・トークン、およびデプロイ・キーとなります。
プロジェクトとファイルの命名
Git Repos and Issue Tracking では、プロジェクトの名前と、プロジェクトリポジトリに保存されているファイルのパス名は、ブラウザ、API、Terraformのどれを使っても、プロジェクトとやりとりするために使うURLのセグメントとなる。 URLは安全ではないと思ってください。 したがって、プロジェクト名やリポジトリファイルのパス名に機密情報を使用したり、埋め込んだりしないでください。
プロジェクトの可視性レベル
Git Repos and Issue Tracking プロジェクトは、プライベート、内部、またはパブリックのいずれかの可視性レベルを持ちます。
- プライベート・プロジェクトは、プロジェクト・メンバーにのみ表示されます。 この設定は、新規プロジェクトのデフォルトの可視性レベルであり、データに対して最も安全な可視性レベルです。
- 社内プロジェクトは、 IBM Cloud にログインしているすべてのユーザーに表示されます。
- パブリック・プロジェクトはすべてのユーザーに表示されます。
プロジェクトへのアクセスをプロジェクト・メンバーのみに制限するには、以下の手順を実行します。
- プロジェクトのサイドバーから、「設定」>**「一般」**をクリックします。
- 「一般設定」ページで、「可視性」>「プロジェクト・フィーチャー」>**「許可」**をクリックします。
- プロジェクトの可視性の設定を見つけます。
- **「プライベート」**を選択します (選択されていない場合)。
- **「変更を保存」**をクリックします。
プロジェクト・メンバーシップ
Git Repos and Issue Tracking は、クラウドでホストされるソーシャル・コーディング環境であり、すべての Continuous Delivery ユーザーが使用できます。 Git Repos and Issue Tracking プロジェクトの保守担当者または所有者は、任意のユーザーおよびグループ・メンバーをプロジェクトに招待できます。 IBM Cloud では、プロジェクトに招待できるユーザーに制限はありません。 GitLab プロジェクトには誰でも招待できるため、特に意図していない限り、会社または組織の一部であるユーザーまたはグループのみを招待するように注意してください。
GitLab プロジェクト・メンバーの管理について詳しくは、 プロジェクトのメンバーを参照してください。
プロジェクト E メール設定
デフォルトでは、Git Repos and Issue Tracking は E メールでプロジェクト・アクティビティーについてプロジェクト・メンバーに通知します。 これらの E メールには通常、ユーザーによって Git Repos and Issue Tracking に提供されたお客様所有のデータが含まれます。 例えば、ユーザーが問題にコメントを投稿した場合、Git Repos and Issue Tracking は、コメントのコピー、コメントを投稿したユーザー、コメントがいつ投稿されたかなどの情報を含む E メールをすべてのサブスクライバーに送信します。 プロジェクトのすべての E メール通知をオフにするには、以下の手順を実行します。
- プロジェクトのサイドバーから、「設定」>**「一般」**をクリックします。
- 「一般設定」ページで、「可視性」>「プロジェクト・フィーチャー」>**「許可」**をクリックします。
- **「E メール通知を無効にする」**チェック・ボックスを選択します。
- **「変更を保存」**をクリックします。
プロジェクトの統合と Web フック
Git Repos and Issue Tracking プロジェクトは、他のシステムへの統合または Web フックを使用して構成されたり、アクセス・トークン、デプロイ・トークン、およびデプロイ・キーを装備している場合もあります。 プロジェクトのサイドバーから、プロジェクトに構成されている統合、Web フック、トークン、およびキーを確認または変更するには、以下の手順を実行します。
- プロジェクトのサイドバーから、**「設定」**をクリックします。
- **「統合」**をクリックして、プロジェクトの他のアプリケーションとの統合を処理します。
- **「Web フック」**をクリックして、他のシステムへのプロジェクトの Web フックを処理します。
- **「アクセス・トークン」**をクリックして、プロジェクトへのアクセス権限を付与するアクセス・トークンを処理します。
- **「デプロイ・トークン」**を展開して、プロジェクトへのアクセス権限を付与するデプロイ・トークンを処理します。
- **「デプロイ・キー」**を展開して、プロジェクトへのアクセス権限を付与するデプロイ・キーを処理します。
Git Repos and Issue Tracking の処理について詳しくは、Git Repos and Issue Tracking を参照してください。
デリバリー・パイプラインを使用する場合のデータの保護
Continuous Delivery パイプラインは、指定されたジョブおよびステップを実行します。 Continuous Delivery サービスは、パイプライン実行によって生成されるログ出力とビルド成果物を安全に管理します。 ただし、Continuous Delivery は、パイプラインのジョブ・スクリプトまたはステップ・スクリプトの機能を制限したり管理したりすることはありません。
パイプラインのジョブ・スクリプトとステップ・スクリプトを開発および構成する場合は、リソースの機密性、保全性、または可用性を損なう可能性があるアクションや、その他の方法で規制管理に違反するようなアクションをスクリプトが実行しないようにしてください。
デリバリーパイプライン add-mask コマンド
Tektonワーカーエージェント(バージョン 0.22.3 +)は、ログ出力のセンシティブな値を行ごとに動的にマスクすることができるadd-mask機能をサポートしています。 ログ行に ::add-mask::{value} パターンが含まれる場合、そのマーカーは出力から削除され、その値はログストリームの残りの部分では *** としてマスクされる。
使用法
add-maskコマンドの使い方を理解するために、以下の例をチェックすることができる。
入力ログ:
Setting up authentication
API Key: ::add-mask::sk_live_abc123xyz
Using API key for requests
API response: {"key": "sk_live_abc123xyz", "status": "ok"}
出力ログ:
Setting up authentication
API Key: ***
Using API key for requests
API response: {"key": "***", "status": "ok"}
仕組みについて
add-mask コマンドを使用すると、システムは以下の手順を実行する:
-
行に
::add-mask::{value}、システムが含まれている:- 出力から
::add-mask::のマーカーを削除する ::add-mask::以降(行末まで)をマスクする値として抽出する- 現在の行の値を
***に置き換える - マスクリストに値を追加する
- 出力から
-
それ以降のすべての行について:
- 以前にマスクされた値が出現した場合は、自動的に次の値に置き換えられます。
***
- 以前にマスクされた値が出現した場合は、自動的に次の値に置き換えられます。
複数のマスク
ログ全体で複数の値をマスクすることができる:
入力:
Setting password ::add-mask::myP@ssw0rd
Setting token ::add-mask::ghp_abc123
Credentials: myP@ssw0rd, token: ghp_abc123
出力:
Setting password ***
Setting token ***
Credentials: ***, token: ***
デリバリー・パイプラインについて詳しくは、パイプラインの処理および Tekton パイプラインの処理を参照してください。
Terraform を使用する際のデータの保護
Terraform を使用して Continuous Delivery リソースを管理する場合、Terraform によって処理される一部の変数、引数、および属性には、パスワードや API トークンなどの秘密値が含まれることがあります。 これらの値は、Terraform 構成言語ファイルで指定することも、Terraform ツールによって取得して Terraform 状態で保管することも、その両方を行うこともできます。 以下のリストは、Terraform を使用するときに保護する必要がある秘密の値の例を示しています。
- IBM Cloud Terraform プロバイダーが IBM Cloudに対する認証に必要とする IAM API キー。 このキーは、Terraform モジュールの
provider "ibm"ブロックのibmcloud_api_key引数で指定されます。 - 一部の
ibm_cd_toolchain_toolリソースおよびデータ・ソース内のパスワード、アクセス・トークン、API キー、またはその他の種類のシークレットを表す引数または属性。 - 一部の
ibm_cd_tekton_pipeline_propertyまたはibm_cd_tekton_pipeline_trigger_propertyリソースまたはデータ・ソースでシークレットとして指定されているプロパティー値。
IBM Cloud Schematics および以下のプラクティスを使用して、機密データの公開を制限します。
- Terraform 変数を使用して、Terraform ブロックに値を挿入します。
- シークレットを安全に管理および共有するには、 IBM Cloud Schematics を使用します。
- IBM Cloud Schematics を使用して、Terraform 状態を安全に管理および共有します。
ibm_cd_toolchain_tool、ibm_cd_tekton_pipeline_property、またはibm_cd_tekton_pipeline_trigger_propertyリソース内でシークレットを指定する場合は、 Continuous Delivery シークレット参照を使用します。
Terraform コマンド・ライン・ツールを使用している場合は、以下のプラクティスを使用して機密データの公開を制限してください。
- Terraform 変数を使用して、Terraform ブロックに値を挿入します。
terraform planやterraform applyなどのコマンドを実行するときに、Terraform コマンド・ライン・ツールが値の入力を求めるプロンプトを出すことができるようにします。- 秘密が含まれている可能性があるため、Terraform 状態へのアクセスを制御します。 ローカル Terraform 状態はプレーン・テキストで記述されます。
ibm_cd_toolchain_tool、ibm_cd_tekton_pipeline_property、またはibm_cd_tekton_pipeline_trigger_propertyリソース内でシークレットを指定する場合は、 Continuous Delivery シークレット参照を使用します。
機密データの漏えいを制限するには、以下の手法を避けてください。
- リソース・ブロック、データ・ブロック、プロバイダー・ブロックなどの Terraform ブロック内に、プレーン・テキストで秘密を書き込みます。
terraform.tfvars、terraform.tfvars.json、*.auto.tfvars、または*.auto.tfvars.jsonファイル内で秘密をプレーン・テキストで記述する。- シークレットが含まれている
terraform.tfvarsファイル、terraform.tfvars.jsonファイル、*.auto.tfvarsファイル、または*.auto.tfvars.jsonファイルをソース・コード・リポジトリーに送信する。 - Terraform 状態をソース・コード・リポジトリーに送信します。
Terraform 設定の処理には、Terraform コマンドラインツールの代わりに を使用してください IBM Cloud Schematics。 IBM Cloud Schematics は、機密性の高い設定プロパティの安全な保存など、いくつかの利点を提供します。
IBM Cloud Schematics について詳しくは、IBM Cloud Schematics の資料を参照してください。
Terraform 状態の機密データについて詳しくは、 Sensitive Data in Stateを参照してください。
Terraform で入力変数を設定する方法について詳しくは、 ルート・モジュール変数への値の割り当てを参照してください。
Continuous Delivery からのデータの削除
Continuous Delivery サービス・インスタンスを削除しても、関連するツールチェーン、ツール統合、ツール、およびデータ (個人データを含む) は削除されません。 ツールチェーン、ツール統合、およびツールとともに保管されるデータを管理および削除する方法について詳しくは、個人データの変更、探索、および削除を参照してください。