動画の文字起こし

DevOps、データ漏洩やワークフローの混乱を避けるために、機密を安全に保管することをどのように確認していますか？

こんにちは、IBM Cloud チームのアレックス・グリーアです。始まる前に、「いいね!」してチャンネル登録してください。

シークレットとは

シークレットとは、エンティティーが通信してサービスに対してアクションを実行することを許可するデジタル資格情報のことです。 この個別情報はアクセス・ポイントを保護します。 では、このパラダイムがどのように存在するかを見てみましょう。

ここでは、ある種のサービスにアクセスする必要があるエンティティーから始めましょう。 サービスはとりあえずあいまいにしておき、何らかのサービスということにしておきます。 このエンティティーがサービスと適切に通信し、ジョブを完了させるために必要なアクションを実行できるようになるには、エンティティーは 2 つのことをサービスに伝える必要があります。1 つは、エンティティーが誰であるかです。これによってサービスは、何があるいは誰がやり取りしようとしているのかを認識できます。 2 つ目は、サービスはそのコンテキストで付与すべき許可のセットを知ることが必要になります。 これらにより、サービスはそのエンティティーがやり取りすることを適切に許可できるようになります。 この相互作用を可能にするのが、私たちが "秘密 "と呼んでいるものだ

この仕組みを確立したら、次はユーザーの場合の例に移りましょう。 ユーザーについては、このユーザーをエンティティーとし、このサービスを開発者とする。 そのために開発レポとやりとりしている。 そのアクセスを再び得るためには、必要性に戻って、認可と許可が必要だ。 特にこの状況では、ユーザーが通信する方法は、ユーザーにユーザー資格情報を付与することです。 これで、そのユーザーは、目的を果たすのに必要な方法で開発リポジトリーとやり取りできるようになります。

さて、クラウド・ネイティブ・アプリケーションのストーリーを見ると、互いに対話しなければならない多くのマイクロサービスがある。 では、それを見てみましょう。 DB "と呼ばれるデータベースとやりとりし、仕事を遂行するために必要な特定の情報を取得する必要があるサービス "A "としよう。 シークレットの形でサービスが必要とするのは、「DB 構成」というものです。 繰り返しになるが、このDBコンフィグによって、私はこういう人間であり、こういうことを成し遂げるためにここに来たのだ、とサービスとの正しいコミュニケーションが可能になる。

しかし、シークレットの例としてDBコンフィグにユーザー認証情報を持っている今、もしこれらの認証情報が悪人の手に渡れば、ここに脆弱性が生まれることに気づく。 そしてこれが、アプリケーションやマイクロサービスを構築していく上で、これらすべてを一元管理する場所を確立することが非常に重要である理由だ。 これらが多くなるほど、問題は複雑になります。 もしそれが悪意のある人の手に渡ったら、どのように保護されているのでしょうか? その核心に到達されるのをどのようにブロックするのでしょうか? そのデータはどのように分離されていたのでしょうか?

これがもたらす可能性がある損害を考えると、例えばデータ・ブリーチの場合、数百万ドルになります。 開発者の操作という観点では、操作を適切に管理していなければ、不正アクターが関与していなかったとしても問題は変わりません。チームでこれを使用すると混乱が生じる可能性があります。 したがって、これらのシークレットを適切な方法で活用し、ユーザーがサービスと適切に通信できるように、不適切に保管されているものを再度一元化しておく必要があります。

よし、では、タマネギの次の層をもっと複雑な例で見てみよう。

ここで、社内開発者のジェーンに戻りましょう。 ジェーンは、「E 開発」ですが、彼女が以前参照していた開発リポジトリーに対するアクセス権限が再び必要になりました。 これを GitHub。 さて、それができるようになるために彼女がしなければならないことは、書き込み権限を持つことです。したがって、彼女は、その役割に対するアクセス権限を彼女に与える情報を要求することが必要になります。 そのために、シークレット・マネージャー・サービスが完全かつ補完的な形で提供されています。

このあとすぐに見るように、シークレット・マネージャー・サービスは、これらの資格情報を他のタイプのシークレットとともに安全かつ一元的に保管し、彼女またはその他のサービスにアクセス権を付与します。 ユーザー資格情報が安全に保管されているので、彼女はサービスでの認証とジョブを完了させることに安心して注意を向けることができます。シークレット・マネージャーが彼女に代わって必要なことを行ってくれるからです。

一方、シークレット・マネージャー・サービスにとって本当に重要なことは、クラウド・サービス・プロバイダーの IAM、つまり Identity and Access Management サービスとのやり取りです。 IAM は、彼女が誰であるかを GitHub に伝えるために、シークレット・マネージャーが認証することを可能にする信頼できる情報源となります。また、2 次的には、IAM サービスの中にあるパラダイムに基づいて適切な役割セットを彼女が取得できるようにします。 ここまでで、ユーザーがシークレット・マネージャー・サービスを使用して適切な許可を取得し、使用するサービスで必要とするツールにアクセスする仕組みについて理解できました。

ところで、サービスが別のサービスとやり取りすることがどういうものか、そしてどのような場合にデータ・ブリーチが有害になる可能性があるかを見てみましょう。

サービス対サービスの例を見てみましょう。 まず融資アプリケーションから始めましょう。 この融資アプリは、アクセス許可を要求します。データベースについては先ほどもお話ししました。 もう少し具体的に説明しよう。このデータベースがアクセスする必要があるのは、データベース内の所定のテーブルであり、消費者だけに提供するかどうかを判断できるようにするために、そのモデルに必要な情報を与える必要がある。 したがって、これをプロファイル・データベースと呼ぶことにします。 ここにプロファイル DB があって、付与したい許可セットが表 A の読み取り権限になることを認識しています。 究極的に、認証へのアクセス権限と必要な許可セットが付与されることになるシークレットをどこに保管するのでしょうか。 それも、提供されたシークレット・マネージャー・サービスになり、そのサービスはもう一度 Cloud IAM と対話する必要があります。 これを確立した今、どのようなタイプの資格情報がここにあるのでしょうか? DB 構成という資格情報が存在しています。 ところで、ウォークスルーしたシナリオについて考えてみましょう。この DB 構成によって、融資アプリケーションが読み取り権限を持てるようになったり、IP データなどの非常に機密性の高い何らかの情報が含まれるデータベース内の特定の表から具体的な情報セットを取得できるようになったりします。 したがって、これらの DB 構成が適切に保管されていなかったり、それらが保管されているサービスが侵害されたりすると、プロバイダーに非常に破滅的なシナリオになります。融資アプリケーションのサービス・プロバイダーは、顧客のところに行き、悪意をもったアクターが不正に得た DB 構成へのアクセスを悪用できたことを知らせる必要があるからです。 そしてその 不適切な DB 構成の結果、悪意を持ったアクターがデータを盗み、顧客に被害を与えることを許してしまったのです。 こうしたリスクを低減するには、安全な場所に保管するか、悪意を持ったアクターがアクセスできないように、企業として満足できるレベルでデータを分離する必要があります。 ここで、シークレット・マネージャー・サービスを活用できます。

繰り返しになりますが、シークレット・マネージャー・サービスはシークレットのセキュア・ストレージを確保するのに役立ちます。これにより、最新の資格情報や他のタイプのシークレットのデータ・ブリーチを心配しなくてもよくなります。 そして最終的には、DevOps 運用中のシークレットの管理の効率が多少なりとも向上します。

今後ともどうぞよろしくお願いいたします。 ご質問がある場合は、ご連絡ください。 このようなビデオを今後もっとご覧になりたい場合は、「いいね!」してチャンネル登録してください。そして IBM Cloud Lab でスキルを高め、バッジを獲得してください。IBM Cloud Lab はブラウザー・ベースの無料の対話式 Kubernetes ラボです。

さまざまなタイプのシークレットの操作

Secrets Manager で作成するシークレットは本来は、静的にも動的にもなり得ます。 静的なシークレットは、シークレットの作成時またはローテーション時に有効期限の日時が設定されます。 対照的に、 動的秘密は保護リソースへのアクセスを必要とするアプリケーションのために、動的に作成されてリースされる固有値 (パスワードや API キーなど)。 動的シークレットがリースの終了に達すると、保護リソースへのアクセスが取り消され、そのシークレットが自動的に削除されます。、その秘密データが読み取られたりアクセスされたりしたときに、その有効期限と時間が強制される。

Secrets Manager はさらに、その一般的な目的または機能によって静的シークレットと動的シークレットに分類します。 例えば、各シークレット・タイプは、username_passwordなどのプログラマチック名によって識別されます。 Secrets ManagerAPIまたはCLIを使用してシークレットを管理する場合は、これらのプログラマチック名を使用して、シークレット・タイプに応じてシークレットに対する操作を実行できます。

次の表で、このサービスで作成および管理できる静的シークレットと動的シークレットのタイプについて説明します。

* サービスでシークレットを作成するには、事前に エンジン構成 が必要です。

シークレット・タイプごとにサポートされる機能

以下の表では、シークレット・タイプ間のいくつかの一般的な特性を比較対照しています。

秘密タイプ間の特徴比較

	任意シークレット	IAM 資格情報	ユーザー資格情報	キー・バリューシークレット	インポートされたた証明書	パブリック証明書	プライベート証明書	サービス資格情報	カスタム資格情報
自動ローテーション		[1]
手動ローテーション
有効期限設定
通知
バージョン履歴
前のバージョンに復元
SDK サポート
CLI プラグイン・サポート
HashiCorp Vault HTTP API の互換性

シークレットの内容

このサービスで保管するシークレットは、メタデータ属性とシークレットの値で構成されます。 メタデータ属性はシークレットを識別するために役立つものです。一方、シークレットの値は、保護されたサービスでユーザーまたはアプリケーションが認証および許可を受けるために必要なデータです。

以下の画像で、シークレットの構成を確認してください。

{
    "name": "my-username-password",
    "id": "cb123456-8e73-4857-594839587438",
    "description": "Description for this secret",
    "secret_type": "username_password",
    "secret_group_id": "ab654321-3958-9484-1395840384754",
    "state": 1,
    "state_description": "Active",
    "create_by": "iam-ServiceId-gj403948-3048-6059-304958674930",
    "created_at": "2023-03-08-T20:44:11Z",
    "labels": [
        "dev",
        "us-south"
    ],
    "username": "user123",
    "password": "cloudy-rainy-coffee-book"
}

1. name、id、およびdescription、およびその他の共通フィールドには、シークレットに関する識別情報が保持されます。 これらのフィールドには、シークレットの目的や履歴を理解するために使用できる一般的な属性が格納されます。

2. シークレットの値を取得するときに返されるフィールドは、シークレットのタイプによって異なります。

   以下の切り捨てられた例は、 arbitrary 秘密のデータがどのように表現されるかを示している。

   {
       "name": "my-secret",
       "secret_type": "arbitrary",
       ...
       "payload": "The quick brown fox jumped over the lazy dog."
   }
   

   以下の切り捨てられた例は、 username_password 秘密のデータがどのように表現されるかを示している。

   {
       "name": "my-secret",
       "secret_type": "username-password",
       ...
       "username": "foo",
       "password": "bar"
   }
   

   以下の切り捨てられた例は、 IAM credential 秘密のデータがどのように表現されるかを示している。

   {
       "name": "my-iam-credentials",
       "secret_type": "iam_credentials",
       ...
       "api_key": "RmnPBn6n1dzoo0v3kyznKEpg0WzdTpW9lW7FtKa017_u",
       "api_key_id": "ApiKey-dcd0b857-b590-4507-8c64-ae89a23e8d76",
       "service_id": "ServiceId-bb4ccc31-bd31-493a-bb58-52ec399800be",
   }
   

   以下の切り捨てられた例は、 KV 秘密のデータがどのように表現されるかを示している。

   {
       "name": "my-kv-secret",
       "secret_type": "kv",
       ...
       "data": '{"key":"value"}'
   }
   

   以下の切り捨てられた例は、 imported_cert シークレットと public_cert シークレットのシークレット・データがどのように表されるかを示しています。

   {
       "name": "my-certificate",
       "secret_type": "imported_cert/public_cert",
       ...
       "certificate":"...",
       "intermediate":"...",
       "private_key":"..."
   }
   

   以下の切り捨てられた例は、 private_cert 秘密のデータがどのように表現されるかを示している。

   {
       "name": "my-certificate",
       "secret_type": "private_cert",
       ...
       "certificate":"...",
       "ca_chain":"...",
       "private_key":"..."
   }
   

   以下の切り捨てられた例は、 service_credentials 秘密のデータがどのように表現されるかを示している。

   {
       "name": "my-secret",
       "secret_type": "service_credential",
       ...
       "credentials": {
           "key": "The quick brown fox jumped over the lazy dog."
           }
   }
   

   以下の切り捨てられた例は、 custom_credentials 秘密のデータがどのように表現されるかを示している。

   {
       "name": "my-secret",
       "secret_type": "custom_credential",
       ...
       "credentials_content": {
           "key": "The quick brown fox jumped over the lazy dog."
           }
   }
   

シークレットの状態と遷移

シークレットは、その存続期間中にいくつかの状態に移行します。これらの状態は、シークレットが存在している期間と、そのシークレットに関連付けられたリソースにアクセスできるかどうかの機能です。

Secrets Manager は、シークレットがライフサイクルのいくつかの状態を通過するのを追跡するためのグラフィカル・ユーザー・インターフェイスとREST APIを提供する。 次の図は、秘密が生成されてから破壊されるまでの間に、どのように状態を通過するかを示している。

開始方法

シークレットの使用を開始するには、Secrets Manager UI の**「シークレット」**ページに移動するか、または API リファレンス をチェックして、プログラムでシークレットを作成する詳細を参照してください。