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

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

データセキュリティ

1 - 独自の バケット を持ち込む (BYOB)

自分のバケットを持ち込む (BYOB) を使用することで、W&B Artifacts やその他の機密性の高いデータを、自分のクラウドやオンプレミスのインフラストラクチャーに保存することができます。専用クラウドまたはSaaS クラウドの場合、バケットに保存したデータは W&B が管理するインフラストラクチャーにコピーされません。

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

BYOB 機能を使用すると、データの一部は W&B の中央データベースに保存され、その他のデータは自分のバケットに保存されます。

データベース

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

バケット

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

設定オプション

ストレージバケットを設定するには、インスタンスレベルまたはチームレベルの二つのスコープがあります。

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

バケットをインスタンスレベルで設定し、組織内の1つ以上のチームでそれぞれ設定することができます。

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

利用可能性マトリックス

以下の表は、異なる W&B サーバーデプロイメントタイプでの BYOB の利用可能性を示しています。 Xは、そのデプロイメントタイプで機能が利用可能であることを示します。

W&B サーバーデプロイメントタイプ インスタンスレベル チームレベル 追加情報
専用クラウド X X Amazon Web Services、Google Cloud Platform、Microsoft Azure のいずれでもインスタンスとチームレベルの BYOB が利用可能です。チームレベルの BYOB については、クラウドネイティブのストレージバケットに同じクラウドまたは別のクラウド、またはあなたのクラウドやオンプレミスのインフラストラクチャーにホストされた MinIO のような S3 互換の安全なストレージにも接続できます。
SaaS クラウド 該当なし X チームレベルの BYOB は Amazon Web Services および Google Cloud Platform のみで利用可能です。W&B は Microsoft Azure のデフォルトで唯一のストレージバケットを完全に管理しています。
セルフマネージド X X インスタンスレベルの BYOB がデフォルトです。なぜなら、インスタンスは完全にあなたによって管理が行われるためです。もしあなたのセルフマネージドインスタンスがクラウドにある場合、チームレベルの BYOB のために同じまたは別のクラウドにクラウドネイティブのストレージバケットに接続できます。また、インスタンスまたはチームレベルの BYOB のいずれかに MinIO のような S3 互換の安全なストレージを使用することもできます。

チームレベル BYOB のためのクロスクラウドまたは S3 互換ストレージ

専用クラウド または セルフマネージド インスタンスにおいて、別のクラウドのクラウドネイティブのストレージバケットまたは MinIO のような S3 互換のストレージバケットに接続して、チームレベル BYOB を利用することができます。

クロスクラウドまたは S3 互換のストレージの利用を有効にするには、次のフォーマットのいずれかを使用してストレージバケットを指定し、W&B インスタンス用のGORILLA_SUPPORTED_FILE_STORES 環境変数を設定します。

専用クラウドまたはセルフマネージドインスタンスでチームレベル BYOB のために S3 互換のストレージを設定する

次のフォーマットを使用してパスを指定します：

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

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

専用クラウドまたはセルフマネージドインスタンスでチームレベル 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>

詳しくは support@wandb.com までお問い合わせください。

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

ユースケースに基づいて、チームまたはインスタンスレベルにストレージバケットを設定します。ストレージバケットが調達または設定される方法は、それがどのレベルで設定されているかにかかわらず同じです。ただし、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 クラウド または 専用クラウド を使用している場合は、<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 チームとバケット名を共有してください。どのデプロイメントタイプにおいてもチームレベルの BYOB の場合、チーム作成時にバケットを設定してください。

      SaaS クラウド または 専用クラウド を使用している場合、<aws_principal_and_role_arn> を次の値で置き換えてください。

詳細については、AWS セルフマネージドホスティングガイドをご覧ください。

  1. GCS バケットのプロビジョニング

    GCP プロジェクト内で GCS バケットをプロビジョニングするために、以下の手順に従います：

    1. 好みの名前で GCS バケットを作成します。必要に応じてフォルダーを作成し、サブパスとして設定して W&B のすべてのファイルを保存します。

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

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

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

    5. UI では不可能なので、gsutil を用いて CORS ポリシーを設定します。

    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 クラウド または 専用クラウド を使用している場合、W&B プラットフォームにリンクされた GCP サービスアカウントに Storage Admin ロールを付与します：

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

    バケット名を記録してください。専用クラウドを使用している場合、インスタンスレベルの BYOB ではバケット名を W&B チームと共有してください。どのデプロイメントタイプにおいてもチームレベルの BYOB の場合、チーム作成時にバケットを設定してください。

  1. Azure Blob Storage のプロビジョニング

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

    • 好みの名前でバケットを作成します。必要に応じてフォルダーを作成し、サブパスとして設定して W&B のすべてのファイルを保存します。

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

    • バージョニングを有効にします。

    • バケットに CORS ポリシーを設定します。

      CORS ポリシーを UI を通じて設定するには、 Blob ストレージに移動し、Settings/Resource Sharing (CORS) までスクロールダウンして、以下を設定します：

      パラメータ 値
      Allowed Origins *
      Allowed Methods GET, HEAD, PUT
      Allowed Headers *
      Exposed Headers *
      Max Age 3600

  2. ストレージ アカウント アクセス キーを生成し、ストレージ アカウント名と共に記録します。専用クラウドを使用している場合、ストレージ アカウント名とアクセス キーを安全な共有方法で W&B チームと共有します。

    チームレベルの BYOB の場合、W&B はTerraformを使用して、必要なアクセスメカニズムと権限と共に Azure Blob Storage バケットをプロビジョニングすることをお勧めします。専用クラウドを使用する場合、インスタンスのための OIDC 発行者 URL を提供します。バケットを設定する際に必要な詳細をメモしてください：

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

W&B での BYOB の設定

W&B チーム作成時にチームレベルでストレージバケットを設定するには：

  1. チーム名 フィールドにチーム名を入力します。

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

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

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

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

  5. 名前 フィールドにストレージバケットの名前を入力します。Azure で 専用クラウド または セルフマネージド インスタンスを持っている場合は、アカウント名 および コンテナ名 の値を入力してください。

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

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

  8. (Azure バケットを使用する場合はオプション) テナントID および マネージド アイデンティティ クライアント ID の値を入力します。

  9. (SaaS クラウドでオプション) チームの作成時にオプションでチームメンバーを招待します。

  10. チームを作成 ボタンを押します。

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

専用クラウドまたはセルフマネージドインスタンスのインスタンスレベル BYOB を設定するには、support@wandb.com まで W&B サポートにお問い合わせください。

2 - BYOB に事前署名済みの URL を使用してアクセスする

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

必要に応じて、ネットワーク内の AI ワークロードまたはユーザー ブラウザー クライアントが W&B プラットフォームから事前署名付き URL を要求します。その後、W&B プラットフォームは関連する blob ストレージにアクセスして、必要な権限で事前署名付き URL を生成し、クライアントに返します。クライアントは、事前署名付き URL を使用して blob ストレージにアクセスし、オブジェクトのアップロードまたは取得操作を行います。オブジェクトのダウンロードの URL は 1 時間で期限切れになり、巨大なオブジェクトをチャンクでアップロードするのに時間がかかる可能性があるため、オブジェクトのアップロードについては 24 時間有効です。

チームレベルのアクセス制御

各事前署名付き URL は、W&B プラットフォームのチームレベルのアクセス制御 に基づいて特定のバケットに限定されます。ユーザーがセキュア ストレージ コネクタを使用して blob ストレージ バケットにマッピングされているチームの一員であり、そのユーザーがそのチームにのみ属している場合、彼らの要求に対して生成された事前署名付き URL には、他のチームにマッピングされている blob ストレージ バケットにアクセスする権限がありません。

ネットワーク制限

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

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

監査ログ

W&B は、blob ストレージ固有の監査ログに加えて、W&B 監査ログを使用することを推奨します。後者については、AWS S3 のアクセスログ、Google Cloud Storage の監査ログ、Azure blob storage の監視を参照してください。管理者とセキュリティ チームは、W&B 製品でどのユーザーが何をしているかを追跡し、特定のユーザーに対していくつかの操作を制限する必要があると判断した場合に必要な対策を講じるために監査ログを使用できます。

3 - 専用クラウドのための IP 許可リストを設定する

You can restrict access to your Dedicated Cloud インスタンスを許可された IP アドレスのリストからのみとすることができます。これは、AI ワークロードから W&B API へのアクセスおよびユーザーのブラウザから W&B アプリの UI へのアクセスにも適用されます。Dedicated Cloud インスタンスに対して IP ホワイトリストが設定されると、W&B は他の許可されていない場所からの要求を拒否します。Dedicated Cloud インスタンスの IP ホワイトリスト設定については、W&B チームにお問い合わせください。

IP ホワイトリストは、AWS、GCP、Azure 上の Dedicated Cloud インスタンスで利用可能です。

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

4 - 専用クラウドへのプライベート接続を設定します

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

安全なプライベート接続は、AWS、GCP、および Azure 上の専用クラウドインスタンスで利用可能です：

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

IP allowlisting とともに安全なプライベート接続を使用できます。IP allowlisting のために安全なプライベート接続を使用する場合、W&B は可能であれば、IP allowlisting を特権的な場所からのインスタンス管理のために使用しつつ、AI ワークロードからのすべてのトラフィックと、ユーザーブラウザからのトラフィックの大部分に対して安全なプライベート接続を確保することをお勧めします。

5 - 専用クラウドでのデータ暗号化

W&B は、クラウドごとの customer-managed encryption key (CMEK) 機能を使用して、各 専用クラウド の W&B 管理データベースとオブジェクトストレージを暗号化するために、W&B 管理のクラウドネイティブキーを使用します。この場合、W&B はクラウドプロバイダの customer として機能し、W&B プラットフォームをサービスとして提供します。W&B 管理のキーを使用するということは、W&B がクラウドごとにデータを暗号化するために使用するキーを管理するということであり、これにより、すべての顧客に対して非常に安全でセキュアなプラットフォームを提供するという約束を強化します。

W&B は、各顧客インスタンスのデータを暗号化するために unique key を使用し、専用クラウドテナント間のもう一つの分離のレイヤーを提供します。この機能は AWS、Azure、GCP で利用可能です。

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

もし組織が専用クラウドを AI ワークフローで使用するために、W&B 管理データベースとオブジェクトストレージを暗号化するために独自のクラウドネイティブキーを使用する必要がある場合、W&B は例外的にレビューを行うことができます。承認された場合、暗号化に独自のクラウドネイティブキーを使用することは、W&B 専用クラウドの shared responsibility model に準拠します。専用クラウドインスタンスが稼働中に組織の任意のユーザーがキーを削除したり、W&B のアクセスを取り消したりした場合、W&B はそれに伴うデータの損失や破損に対して責任を負わず、そのデータの回復も行いません。