これは、このセクションの複数ページの印刷可能なビューです。 印刷するには、ここをクリックしてください.

このページの通常のビューに戻る.

Data security

1 - Bring your own bucket (BYOB)

Bring your own bucket (BYOB) を使用すると、W&B の Artifacts やその他の関連する機密データを、お客様の クラウド または オンプレミス の インフラストラクチャー に保存できます。専用クラウド または SaaS Cloud の場合、お客様の バケット に保存する データ は、W&B が管理する インフラストラクチャー にコピーされません。

中央データベースに保存されるデータと バケット に保存されるデータ

BYOB 機能を使用する場合、特定の種類の データ は W&B 中央データベースに保存され、他の種類の データ はお客様の バケット に保存されます。

データベース

  • ユーザー 、 Teams、Artifacts、Experiments、および Projects の メタデータ
  • Reports
  • Experiment ログ
  • システム メトリクス

バケット

  • Experiment ファイルと メトリクス
  • Artifact ファイル
  • メディア ファイル
  • Run ファイル

設定オプション

ストレージ バケット を構成できる スコープ は、インスタンス レベル または Team レベル の 2 つです。

  • インスタンス レベル: 組織内で関連する 権限 を持つ ユーザー は、インスタンス レベルのストレージ バケット に保存されているファイルに アクセス できます。
  • Team レベル: W&B Team の メンバー は、Team レベルで構成された バケット に保存されているファイルに アクセス できます。Team レベルのストレージ バケット を使用すると、機密性の高い データ や厳格なコンプライアンス要件を持つ Teams に対して、より優れた データ アクセス制御と データ 分離が可能になります。

インスタンス レベルで バケット を構成することも、組織内の 1 つまたは複数の Teams に対して個別に構成することもできます。

たとえば、組織に Kappa という Team があるとします。組織 (および Team Kappa) は、デフォルトでインスタンス レベルのストレージ バケット を使用します。次に、Omega という Team を作成します。Team Omega を作成するときに、その Team の Team レベルのストレージ バケット を構成します。Team Omega によって生成されたファイルは、Team Kappa からは アクセス できません。ただし、Team Kappa によって作成されたファイルは、Team Omega から アクセス できます。Team Kappa の データを分離する場合は、Team レベルのストレージ バケット を構成する必要があります。

可用性マトリックス

次の表は、さまざまな W&B サーバー デプロイメント タイプ における BYOB の可用性を示しています。X は、その機能が特定の デプロイメント タイプ で利用できることを意味します。

W&B サーバー デプロイメント タイプ インスタンス レベル Team レベル 追加情報
専用クラウド X X インスタンス および Team レベルの BYOB は、Amazon Web Services、Google Cloud Platform、および Microsoft Azure で利用できます。Team レベルの BYOB の場合、同じ クラウド または別の クラウド 内の クラウド ネイティブ ストレージ バケット、または クラウド または オンプレミス の インフラストラクチャー でホストされている MinIO などの S3 互換のセキュア ストレージに接続できます。
SaaS Cloud 適用外 X Team レベルの BYOB は、Amazon Web Services と Google Cloud Platform でのみ利用できます。W&B は、Microsoft Azure のデフォルトのストレージ バケット と唯一のストレージ バケット を完全に管理します。
自己管理 X X インスタンス レベルの BYOB は、インスタンス がお客様によって完全に管理されているため、デフォルトです。自己管理 インスタンス が クラウド にある場合、Team レベルの BYOB 用に、同じ クラウド または別の クラウド 内の クラウド ネイティブ ストレージ バケット に接続できます。インスタンス または Team レベルの BYOB のいずれかに対して、MinIO などの S3 互換のセキュア ストレージを使用することもできます。

Team レベルの BYOB 向けのクロス クラウド または S3 互換ストレージ

専用クラウド または 自己管理 インスタンス の Team レベルの BYOB 用に、別の クラウド 内の クラウド ネイティブ ストレージ バケット 、または MinIO などの S3 互換ストレージ バケット に接続できます。

クロス クラウド または S3 互換ストレージの使用を有効にするには、W&B インスタンス の GORILLA_SUPPORTED_FILE_STORES 環境 変数を使用して、次のいずれかの形式で、関連する アクセス キー を含むストレージ バケット を指定します。

専用クラウド または 自己管理 インスタンス で Team レベルの BYOB 用に S3 互換ストレージを構成する

次の形式でパスを指定します。

s3://<accessKey>:<secretAccessKey>@<url_endpoint>/<bucketName>?region=<region>?tls=true

region パラメータ は必須です。ただし、W&B インスタンス が AWS にあり、W&B インスタンス ノード で構成された AWS_REGION が S3 互換ストレージ用に構成された リージョン と一致する場合は除きます。

専用クラウド または 自己管理 インスタンス で Team レベルの BYOB 用にクロス クラウド ネイティブ ストレージを構成する

W&B インスタンス とストレージ バケット の場所固有の形式でパスを指定します。

GCP または Azure の W&B インスタンス から AWS の バケット へ:

s3://<accessKey>:<secretAccessKey>@<s3_regional_url_endpoint>/<bucketName>

GCP または AWS の W&B インスタンス から Azure の バケット へ:

az://:<urlEncodedAccessKey>@<storageAccountName>/<containerName>

AWS または Azure の W&B インスタンス から GCP の バケット へ:

gs://<serviceAccountEmail>:<urlEncodedPrivateKey>@<bucketName>

詳細については、W&B サポート (support@wandb.com) までお問い合わせください。

W&B プラットフォーム と同じ クラウド 内の クラウド ストレージ

ユースケース に基づいて、Team または インスタンス レベルでストレージ バケット を構成します。ストレージ バケット のプロビジョニングまたは構成方法は、Azure の アクセス メカニズムを除き、構成されているレベルに関係なく同じです。

  1. KMS キー をプロビジョニングします。

    W&B では、S3 バケット 上の データを 暗号化および復号化するために、KMS キー をプロビジョニングする必要があります。キー の使用タイプは ENCRYPT_DECRYPT である必要があります。次の ポリシー を キー に割り当てます。

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid" : "Internal",
      "Effect" : "Allow",
      "Principal" : { "AWS" : "<Your_Account_Id>" },
      "Action" : "kms:*",
      "Resource" : "<aws_kms_key.key.arn>"
    },
    {
      "Sid" : "External",
      "Effect" : "Allow",
      "Principal" : { "AWS" : "<aws_principal_and_role_arn>" },
      "Action" : [
        "kms:Decrypt",
        "kms:Describe*",
        "kms:Encrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*"
      ],
      "Resource" : "<aws_kms_key.key.arn>"
    }
  ]
}

    <Your_Account_Id> と <aws_kms_key.key.arn> を適宜置き換えます。

    SaaS Cloud または 専用クラウド を使用している場合は、<aws_principal_and_role_arn> を対応する 値 に置き換えます。

    この ポリシー は、AWS アカウント に キー へのフル アクセス を許可し、W&B プラットフォーム をホストする AWS アカウント に必要な 権限 も割り当てます。KMS キー ARN の記録を保持します。

  2. S3 バケット をプロビジョニングします。

    次の手順に従って、AWS アカウント で S3 バケット をプロビジョニングします。

    1. 任意の名前で S3 バケット を作成します。オプションで、すべての W&B ファイルを保存するためのサブパスとして構成できるフォルダーを作成します。

    2. バケット の バージョン管理 を有効にします。

    3. 前のステップの KMS キー を使用して、サーバー 側の 暗号化 を有効にします。

    4. 次の ポリシー で CORS を構成します。

      [
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "HEAD",
            "PUT"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": [
            "ETag"
        ],
        "MaxAgeSeconds": 3600
    }
]

    5. W&B プラットフォーム をホストする AWS アカウント に必要な S3 権限 を付与します。これには、お客様の クラウド インフラストラクチャー または ユーザー の ブラウザー 内の AI ワークロード が バケット への アクセス に使用する 事前署名付き URL を生成するための 権限 が必要です。

      {
  "Version": "2012-10-17",
  "Id": "WandBAccess",
  "Statement": [
    {
      "Sid": "WAndBAccountAccess",
      "Effect": "Allow",
      "Principal": { "AWS": "<aws_principal_and_role_arn>" },
        "Action" : [
          "s3:GetObject*",
          "s3:GetEncryptionConfiguration",
          "s3:ListBucket",
          "s3:ListBucketMultipartUploads",
          "s3:ListBucketVersions",
          "s3:AbortMultipartUpload",
          "s3:DeleteObject",
          "s3:PutObject",
          "s3:GetBucketCORS",
          "s3:GetBucketLocation",
          "s3:GetBucketVersioning"
        ],
      "Resource": [
        "arn:aws:s3:::<wandb_bucket>",
        "arn:aws:s3:::<wandb_bucket>/*"
      ]
    }
  ]
}

      <wandb_bucket> を適宜置き換え、 バケット 名の記録を保持します。専用クラウド を使用している場合は、インスタンス レベルの BYOB の場合に備えて、 バケット 名を W&B Team と共有します。任意の デプロイメント タイプ の Team レベルの BYOB の場合は、Team の作成中に バケット を構成します。

      SaaS Cloud または 専用クラウド を使用している場合は、<aws_principal_and_role_arn> を対応する 値 に置き換えます。

詳細については、AWS 自己管理 ホスティング ガイド を参照してください。

  1. GCS バケット をプロビジョニングします。

    次の手順に従って、GCP プロジェクト で GCS バケット をプロビジョニングします。

    1. 任意の名前で GCS バケット を作成します。オプションで、すべての W&B ファイルを保存するためのサブパスとして構成できるフォルダーを作成します。

    2. ソフト削除を有効にします。

    3. オブジェクト の バージョン管理 を有効にします。

    4. 暗号化 タイプ を Google-managed に設定します。

    5. gsutil で CORS ポリシー を設定します。これは UI では実行できません。

    6. cors-policy.json というファイルをローカルに作成します。

    7. 次の CORS ポリシー をファイルにコピーして保存します。

      [
{
  "origin": ["*"],
  "responseHeader": ["Content-Type"],
  "exposeHeaders": ["ETag"],
  "method": ["GET", "HEAD", "PUT"],
  "maxAgeSeconds": 3600
}
]

    8. <bucket_name> を正しい バケット 名に置き換え、gsutil を実行します。

      gsutil cors set cors-policy.json gs://<bucket_name>

    9. バケット の ポリシー を確認します。<bucket_name> を正しい バケット 名に置き換えます。

      gsutil cors get gs://<bucket_name>

  2. SaaS Cloud または 専用クラウド を使用している場合は、W&B プラットフォーム にリンクされている GCP サービス アカウント に Storage Admin ロール を付与します。

    • SaaS Cloud の場合、アカウント は wandb-integration@wandb-production.iam.gserviceaccount.com です。
    • 専用クラウド の場合、アカウント は deploy@wandb-production.iam.gserviceaccount.com です。

    バケット 名の記録を保持します。専用クラウド を使用している場合は、インスタンス レベルの BYOB の場合に備えて、 バケット 名を W&B Team と共有します。任意の デプロイメント タイプ の Team レベルの BYOB の場合は、Team の作成中に バケット を構成します。

  1. Azure Blob Storage をプロビジョニングします。

    インスタンス レベルの BYOB の場合、この Terraform モジュール を使用していない場合は、次の手順に従って Azure サブスクリプション で Azure Blob Storage バケット をプロビジョニングします。

    • 任意の名前で バケット を作成します。オプションで、すべての W&B ファイルを保存するためのサブパスとして構成できるフォルダーを作成します。

    • BLOB とコンテナー のソフト削除を有効にします。

    • バージョン管理 を有効にします。

    • バケット で CORS ポリシー を構成します。

      UI から CORS ポリシー を設定するには、BLOB ストレージに移動し、[設定] -> [リソース共有 (CORS)] までスクロールして、次のように設定します。

      パラメータ 値
      許可される オリジン *
      許可される メソッド GET、HEAD、PUT
      許可される ヘッダー *
      公開される ヘッダー *
      最大年齢 3600

  2. ストレージ アカウント の アクセス キー を生成し、ストレージ アカウント 名とともに記録を保持します。専用クラウド を使用している場合は、安全な共有メカニズムを使用して、ストレージ アカウント 名と アクセス キー を W&B Team と共有します。

    Team レベルの BYOB の場合、W&B では、必要な アクセス メカニズムと 権限 とともに Azure Blob Storage バケット をプロビジョニングするために、Terraform を使用することを推奨します。専用クラウド を使用する場合は、インスタンス の OIDC 発行者 URL を指定します。Team の作成中に バケット を構成する ために必要な詳細をメモしておきます。

    • ストレージ アカウント 名
    • ストレージ コンテナー 名
    • マネージド ID クライアント ID
    • Azure テナント ID

W&B で BYOB を構成する

W&B Team を作成するときに Team レベルでストレージ バケット を構成するには:

  1. [Team 名] フィールドに Team の名前を入力します。

  2. [ストレージ タイプ] オプションで [外部ストレージ] を選択します。

  3. ドロップダウンから [新しい バケット ] を選択するか、既存の バケット を選択します。

    複数の W&B Teams が同じ クラウド ストレージ バケット を使用できます。これを有効にするには、ドロップダウンから既存の クラウド ストレージ バケット を選択します。

  4. [クラウド プロバイダー] ドロップダウンから、 クラウド プロバイダーを選択します。

  5. [名前] フィールドにストレージ バケット の名前を入力します。専用クラウド または Azure 上の 自己管理 インスタンス がある場合は、[アカウント 名] フィールドと [コンテナー 名] フィールドに値を入力します。

  6. (オプション) オプションの [パス] フィールドに バケット サブパスを入力します。W&B が バケット のルートにあるフォルダーにファイルを保存しないようにする場合は、これを行います。

  7. (AWS バケット を使用している場合はオプション) [KMS キー ARN] フィールドに KMS 暗号化 キー の ARN を入力します。

  8. (Azure バケット を使用している場合はオプション) [テナント ID] フィールドと [マネージド ID クライアント ID] フィールドに値を入力します。

  9. (SaaS Cloud ではオプション) Team の作成時に Team メンバー を招待します。

  10. [Team を作成] ボタンを押します。

バケット への アクセス に問題がある場合、または バケット の 設定 が無効な場合、ページの下部に エラー または 警告 が表示されます。

専用クラウド または 自己管理 インスタンス の インスタンス レベルの BYOB を構成するには、W&B サポート (support@wandb.com) までお問い合わせください。

2 - Access BYOB using pre-signed URLs

W&B は、AI ワークロードまたは ユーザー のブラウザーからの blob ストレージへの アクセス を簡素化するために、事前署名付き URL を使用します。事前署名付き URL の基本情報については、AWS S3 の事前署名付き URL、Google Cloud Storage の署名付き URL、Azure Blob Storage の Shared Access Signature を参照してください。

必要な場合、ネットワーク内の AI ワークロードまたは ユーザー ブラウザー クライアントは、W&B Platform から事前署名付き URL を要求します。W&B Platform は、関連する blob ストレージに アクセス し、必要な権限を持つ事前署名付き URL を生成し、クライアントに返します。次に、クライアントは事前署名付き URL を使用して blob ストレージに アクセス し、 オブジェクト のアップロードまたは取得操作を行います。 オブジェクト のダウンロードの URL 有効期限は 1 時間、 オブジェクト のアップロードは 24 時間です。これは、一部の大きな オブジェクト をチャンク単位でアップロードするのに時間がかかる場合があるためです。

Team レベルの アクセス 制御

各事前署名付き URL は、W&B platform の team level access control に基づいて、特定の バケット に制限されています。 ユーザー が secure storage connector を使用して blob ストレージ バケット にマッピングされている team の一部であり、その ユーザー がその team の一部である場合、リクエスト に対して生成された事前署名付き URL には、他の team にマッピングされた blob ストレージ バケット に アクセス する権限はありません。

ネットワーク制限

W&B は、 バケット で IAM ポリシー ベースの制限を使用することにより、事前署名付き URL を使用して blob ストレージに アクセス できるネットワークを制限することをお勧めします。

AWS の場合、VPC または IP アドレス ベースのネットワーク制限 を使用できます。これにより、W&B 固有の バケット には、AI ワークロードが実行されているネットワークからのみ、または ユーザー が W&B UI を使用して アーティファクト に アクセス する場合、 ユーザー マシンにマッピングされるゲートウェイ IP アドレスからのみ アクセス されるようになります。

監査 ログ

W&B は、blob ストレージ 固有の 監査 ログ に加えて、W&B audit logs を使用することもお勧めします。後者については、AWS S3 access logs、Google Cloud Storage audit logs および Monitor Azure blob storage を参照してください。管理者およびセキュリティ team は、 監査 ログ を使用して、W&B 製品でどの ユーザー が何をしているかを追跡し、特定の ユーザー に対して一部の操作を制限する必要があると判断した場合に必要なアクションを実行できます。

3 - Configure IP allowlisting for Dedicated Cloud

専用クラウド インスタンスへの アクセス を、許可された IP アドレス のリストのみに制限できます。これは、AI ワークロードから W&B API への アクセス と、 ユーザー のブラウザーから W&B アプリ UI への アクセス の両方に適用されます。 専用クラウド インスタンスに対して IP アドレス許可リストが設定されると、W&B は許可されていない場所からのリクエストをすべて拒否します。 専用クラウド インスタンスの IP アドレス許可リストを構成するには、W&B チームにお問い合わせください。

IP アドレス許可リストは、AWS、GCP、Azure の 専用クラウド インスタンスで利用できます。

IP アドレス許可リストは、セキュアプライベート接続 で使用できます。セキュアプライベート接続で IP アドレス許可リストを使用する場合、W&B は、AI ワークロードからのすべてのトラフィックと、可能な場合は ユーザー ブラウザーからのトラフィックの大部分にセキュアプライベート接続を使用し、特権のある場所からのインスタンス管理には IP アドレス許可リストを使用することをお勧めします。

4 - Configure private connectivity to Dedicated Cloud

専用クラウドインスタンスには、クラウドプロバイダーのセキュアなプライベートネットワーク経由で接続できます。これは、AI ワークロードから W&B API へのアクセス、およびオプションで ユーザー のブラウザーから W&B アプリ UI へのアクセスに適用されます。プライベート接続を使用する場合、関連するリクエストとレスポンスは、パブリックネットワークまたはインターネットを経由しません。

セキュアなプライベート接続は、AWS、GCP、Azure の Dedicated Cloud インスタンスで利用できます。

有効にすると、W&B はインスタンス用のプライベートエンドポイントサービスを作成し、接続するための関連する DNS URI を提供します。これにより、クラウドアカウントにプライベートエンドポイントを作成し、関連するトラフィックをプライベートエンドポイントサービスにルーティングできます。プライベートエンドポイントは、クラウド VPC または VNet 内で実行されている AI トレーニング ワークロードのセットアップが容易です。ユーザー のブラウザーから W&B アプリ UI へのトラフィックに同じメカニズムを使用するには、企業ネットワークからクラウドアカウントのプライベートエンドポイントへの適切な DNS ベースのルーティングを構成する必要があります。

セキュアなプライベート接続は、IP 許可リストで使用できます。IP 許可リストにセキュアなプライベート接続を使用する場合、W&B は、AI ワークロードからのすべてのトラフィック、および可能な場合は ユーザー のブラウザーからのトラフィックの大部分に対してセキュアなプライベート接続を保護し、特権のある場所からのインスタンス管理には IP 許可リストを使用することをお勧めします。

5 - Data encryption in Dedicated cloud

W&B は、各 専用クラウド で、W&B が管理するクラウドネイティブな キー を使用して、W&B が管理するデータベースと オブジェクト ストレージを暗号化します。これは、各 クラウド における顧客管理の暗号化キー (CMEK) 機能を使用することで実現しています。この場合、W&B は クラウド プロバイダーの「顧客」として機能し、W&B プラットフォーム をサービスとして提供します。W&B 管理の キー を使用するということは、W&B が各 クラウド で データを暗号化するために使用する キー を管理できることを意味し、すべてのお客様に高度に安全な プラットフォーム を提供するという約束を強化することになります。

W&B は、各顧客インスタンス内の データを暗号化するために「一意の キー 」を使用し、専用クラウド テナント間の分離をさらに強化します。この機能は、AWS、Azure、GCP で利用できます。

W&B は通常、お客様が独自のクラウドネイティブな キー を持ち込んで、専用クラウド インスタンス内の W&B が管理するデータベースと オブジェクト ストレージを暗号化することを許可していません。これは、組織内の複数の Teams と担当者が、さまざまな理由で クラウド インフラストラクチャー にアクセスできる可能性があるためです。これらの Teams または担当者の中には、組織のテクノロジー スタックにおける重要なコンポーネントとしての W&B に関する知識がない場合があり、クラウドネイティブな キー を完全に削除したり、W&B の アクセス を取り消したりする可能性があります。このような行為は、組織の W&B インスタンス内のすべての データを破損させ、回復不能な状態にする可能性があります。

組織が独自のクラウドネイティブな キー を使用して、W&B が管理するデータベースと オブジェクト ストレージを暗号化し、AI ワークフロー での 専用クラウド の使用を承認する必要がある場合、W&B は例外ベースでそれをレビューできます。承認された場合、暗号化にクラウドネイティブな キー を使用することは、W&B 専用クラウド の「責任共有モデル」に準拠します。組織内の ユーザー が、専用クラウド インスタンスが稼働しているときに、キー を削除したり、W&B の アクセス を取り消したりした場合、W&B は結果として生じる データ の損失または破損について責任を負わず、そのような データの回復についても責任を負いません。