이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.

Data security

1: Bring your own bucket (BYOB)
2: Access BYOB using pre-signed URLs
3: Configure IP allowlisting for Dedicated Cloud
4: Configure private connectivity to Dedicated Cloud
5: Data encryption in Dedicated cloud

1 - Bring your own bucket (BYOB)

Bring your own bucket(BYOB)을 사용하면 W&B 아티팩트 및 기타 관련 민감한 데이터를 자체 클라우드 또는 온프레미스 인프라에 저장할 수 있습니다. 전용 클라우드 또는 SaaS Cloud의 경우 버킷에 저장하는 데이터는 W&B 관리 인프라에 복사되지 않습니다.

W&B SDK / CLI / UI와 버킷 간의 통신은 사전 서명된 URL을 사용하여 이루어집니다.
W&B는 가비지 컬렉션 프로세스를 사용하여 W&B Artifacts를 삭제합니다. 자세한 내용은 Artifacts 삭제를 참조하세요.
버킷을 구성할 때 하위 경로를 지정하여 W&B가 버킷 루트의 폴더에 파일을 저장하지 않도록 할 수 있습니다. 이는 조직의 버킷 관리 정책을 준수하는 데 도움이 될 수 있습니다.

중앙 데이터베이스와 버킷에 저장되는 데이터

BYOB 기능을 사용할 때 특정 유형의 데이터는 W&B 중앙 데이터베이스에 저장되고 다른 유형은 버킷에 저장됩니다.

데이터베이스

사용자, 팀, 아티팩트, Experiments 및 프로젝트에 대한 메타데이터
Reports
Experiment 로그
시스템 메트릭

버킷

Experiment 파일 및 메트릭
Artifact 파일
미디어 파일
Run 파일

설정 옵션

스토리지 버킷을 구성할 수 있는 범위는 인스턴스 수준 또는 팀 수준의 두 가지입니다.

인스턴스 수준: 조직 내에서 관련 권한을 가진 모든 사용자가 인스턴스 수준 스토리지 버킷에 저장된 파일에 엑세스할 수 있습니다.
팀 수준: W&B Teams의 팀 멤버는 팀 수준에서 구성된 버킷에 저장된 파일에 엑세스할 수 있습니다. 팀 수준 스토리지 버킷은 매우 민감한 데이터 또는 엄격한 규정 준수 요구 사항이 있는 팀을 위해 더 강력한 데이터 엑세스 제어 및 데이터 격리를 제공합니다.

인스턴스 수준에서 버킷을 구성하고 조직 내의 하나 이상의 팀에 대해 별도로 구성할 수 있습니다.

예를 들어 조직에 Kappa라는 팀이 있다고 가정합니다. 조직(및 Team Kappa)은 기본적으로 인스턴스 수준 스토리지 버킷을 사용합니다. 다음으로 Omega라는 팀을 만듭니다. Team Omega를 만들 때 해당 팀에 대한 팀 수준 스토리지 버킷을 구성합니다. Team Omega에서 생성된 파일은 Team Kappa에서 엑세스할 수 없습니다. 그러나 Team Kappa에서 만든 파일은 Team Omega에서 엑세스할 수 있습니다. Team Kappa에 대한 데이터를 격리하려면 해당 팀에 대한 팀 수준 스토리지 버킷도 구성해야 합니다.

팀 수준 스토리지 버킷은 특히 다양한 사업부 및 부서가 인프라 및 관리 리소스를 효율적으로 활용하기 위해 인스턴스를 공유할 때 자체 관리 인스턴스에 대해 동일한 이점을 제공합니다. 이는 별도의 고객 참여에 대한 AI 워크플로우를 관리하는 별도의 프로젝트 팀이 있는 회사에도 적용됩니다.

가용성 매트릭스

다음 표는 다양한 W&B 서버 배포 유형에서 BYOB의 가용성을 보여줍니다. X는 특정 배포 유형에서 기능을 사용할 수 있음을 의미합니다.

W&B 서버 배포 유형	인스턴스 수준	팀 수준	추가 정보
전용 클라우드	X	X	인스턴스 및 팀 수준 BYOB는 Amazon Web Services, Google Cloud Platform 및 Microsoft Azure에서 사용할 수 있습니다. 팀 수준 BYOB의 경우 동일하거나 다른 클라우드의 클라우드 네이티브 스토리지 버킷 또는 클라우드 또는 온프레미스 인프라에서 호스팅되는 MinIO와 같은 S3 호환 보안 스토리지에 연결할 수 있습니다.
SaaS Cloud	해당 사항 없음	X	팀 수준 BYOB는 Amazon Web Services 및 Google Cloud Platform에서만 사용할 수 있습니다. W&B는 Microsoft Azure에 대한 기본 및 유일한 스토리지 버킷을 완전히 관리합니다.
자체 관리	X	X	인스턴스가 사용자에 의해 완전히 관리되므로 인스턴스 수준 BYOB가 기본값입니다. 자체 관리 인스턴스가 클라우드에 있는 경우 팀 수준 BYOB에 대해 동일하거나 다른 클라우드의 클라우드 네이티브 스토리지 버킷에 연결할 수 있습니다. 인스턴스 또는 팀 수준 BYOB에 MinIO와 같은 S3 호환 보안 스토리지를 사용할 수도 있습니다.

전용 클라우드 또는 자체 관리 인스턴스에 대해 인스턴스 또는 팀 수준 스토리지 버킷을 구성하거나 SaaS Cloud 계정에 대해 팀 수준 스토리지 버킷을 구성하면 해당 범위에 대한 스토리지 버킷을 변경하거나 재구성할 수 없습니다. 여기에는 데이터를 다른 버킷으로 마이그레이션하고 주요 제품 스토리지에서 관련 참조를 다시 매핑할 수 없는 것도 포함됩니다. W&B는 인스턴스 또는 팀 수준 범위에 대해 구성하기 전에 스토리지 버킷 레이아웃을 신중하게 계획할 것을 권장합니다. 질문이 있으면 W&B 팀에 문의하십시오.

팀 수준 BYOB를 위한 크로스 클라우드 또는 S3 호환 스토리지

전용 클라우드 또는 자체 관리 인스턴스에서 팀 수준 BYOB에 대해 다른 클라우드의 클라우드 네이티브 스토리지 버킷 또는 MinIO와 같은 S3 호환 스토리지 버킷에 연결할 수 있습니다.

크로스 클라우드 또는 S3 호환 스토리지 사용을 활성화하려면 W&B 인스턴스에 대한 GORILLA_SUPPORTED_FILE_STORES 환경 변수를 사용하여 다음 형식 중 하나로 관련 엑세스 키를 포함하는 스토리지 버킷을 지정합니다.

전용 클라우드 또는 자체 관리 인스턴스에서 팀 수준 BYOB에 대한 S3 호환 스토리지 구성

다음 형식을 사용하여 경로를 지정합니다.

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

W&B 인스턴스가 AWS에 있고 W&B 인스턴스 노드에 구성된 AWS_REGION이 S3 호환 스토리지에 구성된 지역과 일치하는 경우를 제외하고 region 파라미터는 필수입니다.

전용 클라우드 또는 자체 관리 인스턴스에서 팀 수준 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>

팀 수준 BYOB에 대한 S3 호환 스토리지 연결은 SaaS Cloud에서 사용할 수 없습니다. 또한 팀 수준 BYOB에 대한 AWS 버킷 연결은 해당 인스턴스가 GCP에 있으므로 SaaS Cloud에서 크로스 클라우드입니다. 해당 크로스 클라우드 연결은 이전에 전용 클라우드 및 자체 관리 인스턴스에 대해 설명한 대로 엑세스 키 및 환경 변수 기반 메커니즘을 사용하지 않습니다.

자세한 내용은 support@wandb.com으로 W&B 지원팀에 문의하십시오.

W&B 플랫폼과 동일한 클라우드의 클라우드 스토리지

유스 케이스에 따라 팀 또는 인스턴스 수준에서 스토리지 버킷을 구성합니다. 스토리지 버킷을 프로비저닝하거나 구성하는 방법은 Azure의 엑세스 메커니즘을 제외하고 구성된 수준에 관계없이 동일합니다.

W&B는 필요한 엑세스 메커니즘 및 관련 IAM 권한과 함께 스토리지 버킷을 프로비저닝하기 위해 W&B에서 관리하는 Terraform 모듈을 사용하는 것이 좋습니다.

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>을 해당 값으로 바꿉니다.

SaaS Cloud: arn:aws:iam::725579432336:role/WandbIntegration
전용 클라우드: arn:aws:iam::830241207209:root

이 정책은 AWS 계정에 키에 대한 모든 엑세스 권한을 부여하고 W&B 플랫폼을 호스팅하는 AWS 계정에 필요한 권한을 할당합니다. KMS 키 ARN을 기록해 둡니다.

S3 버킷 프로비저닝

다음 단계에 따라 AWS 계정에서 S3 버킷을 프로비저닝합니다.

원하는 이름으로 S3 버킷을 만듭니다. 선택적으로 모든 W&B 파일을 저장하기 위해 하위 경로로 구성할 수 있는 폴더를 만듭니다.
버킷 버전 관리를 활성화합니다.
이전 단계에서 KMS 키를 사용하여 서버 측 암호화를 활성화합니다.

다음 정책으로 CORS를 구성합니다.

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

클라우드 인프라 또는 사용자 브라우저의 AI 워크로드가 버킷에 엑세스하는 데 사용하는 사전 서명된 URL을 생성하는 데 필요한 권한인 W&B 플랫폼을 호스팅하는 AWS 계정에 필요한 S3 권한을 부여합니다.

{
  "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 Cloud 또는 전용 클라우드를 사용하는 경우 <aws_principal_and_role_arn>을 해당 값으로 바꿉니다.

SaaS Cloud: arn:aws:iam::725579432336:role/WandbIntegration
전용 클라우드: arn:aws:iam::830241207209:root

자세한 내용은 AWS 자체 관리 호스팅 가이드를 참조하십시오.

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>
```
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 팀과 공유합니다. 모든 배포 유형에서 팀 수준 BYOB의 경우 팀을 만드는 동안 버킷을 구성합니다.

Azure Blob Storage 프로비저닝

인스턴스 수준 BYOB의 경우 이 Terraform 모듈을 사용하지 않는 경우 아래 단계에 따라 Azure 구독에서 Azure Blob Storage 버킷을 프로비저닝합니다.

원하는 이름으로 버킷을 만듭니다. 선택적으로 모든 W&B 파일을 저장하기 위해 하위 경로로 구성할 수 있는 폴더를 만듭니다.
Blob 및 컨테이너 소프트 삭제를 활성화합니다.
버전 관리를 활성화합니다.

버킷에서 CORS 정책을 구성합니다.

UI를 통해 CORS 정책을 설정하려면 Blob Storage로 이동하여 설정/리소스 공유(CORS)로 스크롤한 다음 다음을 설정합니다.

파라미터	값
허용된 원본	`*`
허용된 메소드	`GET`, `HEAD`, `PUT`
허용된 헤더	`*`
노출된 헤더	`*`
최대 사용 기간	`3600`

스토리지 계정 엑세스 키를 생성하고 스토리지 계정 이름과 함께 기록해 둡니다. 전용 클라우드를 사용하는 경우 보안 공유 메커니즘을 사용하여 스토리지 계정 이름과 엑세스 키를 W&B 팀과 공유합니다.

팀 수준 BYOB의 경우 W&B는 필요한 엑세스 메커니즘 및 권한과 함께 Azure Blob Storage 버킷을 프로비저닝하기 위해 Terraform을 사용하는 것이 좋습니다. 전용 클라우드를 사용하는 경우 인스턴스에 대한 OIDC 발급자 URL을 제공합니다. 팀을 만드는 동안 버킷을 구성하는 데 필요한 세부 정보를 기록해 둡니다.
- 스토리지 계정 이름
- 스토리지 컨테이너 이름
- 관리 ID 클라이언트 ID
- Azure 테넌트 ID

W&B에서 BYOB 구성

전용 클라우드 또는 자체 관리 인스턴스에서 팀 수준 BYOB에 대해 다른 클라우드의 클라우드 네이티브 스토리지 버킷 또는 MinIO와 같은 S3 호환 스토리지 버킷에 연결하는 경우 팀 수준 BYOB에 대한 크로스 클라우드 또는 S3 호환 스토리지를 참조하십시오. 이러한 경우 아래 지침을 사용하여 팀에 대해 구성하기 전에 W&B 인스턴스에 대한 GORILLA_SUPPORTED_FILE_STORES 환경 변수를 사용하여 스토리지 버킷을 지정해야 합니다.

보안 스토리지 커넥터가 작동하는 것을 보여주는 비디오 (9분)를 시청하십시오.

W&B Team을 만들 때 팀 수준에서 스토리지 버킷을 구성하려면:

팀 이름 필드에 팀 이름을 입력합니다.
스토리지 유형 옵션에서 외부 스토리지를 선택합니다.
드롭다운에서 새 버킷을 선택하거나 기존 버킷을 선택합니다.

여러 W&B Teams가 동일한 클라우드 스토리지 버킷을 사용할 수 있습니다. 이를 활성화하려면 드롭다운에서 기존 클라우드 스토리지 버킷을 선택합니다.
클라우드 공급자 드롭다운에서 클라우드 공급자를 선택합니다.
이름 필드에 스토리지 버킷 이름을 입력합니다. 전용 클라우드 또는 Azure의 자체 관리 인스턴스가 있는 경우 계정 이름 및 컨테이너 이름 필드에 값을 입력합니다.
(선택 사항) 선택적 경로 필드에 버킷 하위 경로를 입력합니다. W&B가 버킷 루트의 폴더에 파일을 저장하지 않으려면 이 작업을 수행합니다.
(AWS 버킷을 사용하는 경우 선택 사항) KMS 키 ARN 필드에 KMS 암호화 키의 ARN을 입력합니다.
(Azure 버킷을 사용하는 경우 선택 사항) 테넌트 ID 및 관리 ID 클라이언트 ID 필드에 값을 입력합니다.
(SaaS Cloud에서 선택 사항) 팀을 만들 때 팀 멤버를 초대할 수도 있습니다.
팀 만들기 버튼을 누릅니다.

버킷에 엑세스하는 데 문제가 있거나 버킷에 잘못된 설정이 있는 경우 페이지 하단에 오류 또는 경고가 나타납니다.

전용 클라우드 또는 자체 관리 인스턴스에 대한 인스턴스 수준 BYOB를 구성하려면 support@wandb.com으로 W&B 지원팀에 문의하십시오.

2 - Access BYOB using pre-signed URLs

W&B는 AI 워크로드 또는 사용자 브라우저에서 blob storage에 대한 엑세스를 간소화하기 위해 사전 서명된 URL을 사용합니다. 사전 서명된 URL에 대한 기본 정보는 AWS S3용 사전 서명된 URL, Google Cloud Storage용 서명된 URL 및 Azure Blob Storage용 공유 엑세스 서명을 참조하십시오.

필요한 경우 네트워크 내의 AI 워크로드 또는 사용자 브라우저 클라이언트가 W&B Platform에서 사전 서명된 URL을 요청합니다. 그러면 W&B Platform은 관련 blob storage에 엑세스하여 필요한 권한으로 사전 서명된 URL을 생성하고 클라이언트에 다시 반환합니다. 그런 다음 클라이언트는 사전 서명된 URL을 사용하여 오브젝트 업로드 또는 검색 작업을 위해 blob storage에 엑세스합니다. 오브젝트 다운로드를 위한 URL 만료 시간은 1시간이고, 일부 대형 오브젝트는 청크 단위로 업로드하는 데 더 많은 시간이 필요할 수 있으므로 오브젝트 업로드는 24시간입니다.

팀 레벨 엑세스 제어

각 사전 서명된 URL은 W&B platform의 팀 레벨 엑세스 제어를 기반으로 특정 버킷으로 제한됩니다. 사용자가 보안 스토리지 커넥터를 사용하여 blob storage 버킷에 매핑된 팀에 속하고 해당 사용자만 해당 팀에 속한 경우, 해당 요청에 대해 생성된 사전 서명된 URL은 다른 팀에 매핑된 blob storage 버킷에 엑세스할 수 있는 권한이 없습니다.

W&B는 사용자를 자신이 속해야 하는 팀에만 추가할 것을 권장합니다.

네트워크 제한

W&B는 버킷에 대한 IAM 정책 기반 제한을 사용하여 사전 서명된 URL을 사용하여 blob storage에 엑세스할 수 있는 네트워크를 제한하는 것이 좋습니다.

AWS의 경우 VPC 또는 IP 어드레스 기반 네트워크 제한을 사용할 수 있습니다. 이렇게 하면 W&B 특정 버킷이 AI 워크로드가 실행 중인 네트워크 또는 사용자가 W&B UI를 사용하여 Artifacts에 엑세스하는 경우 사용자 머신에 매핑되는 게이트웨이 IP 어드레스에서만 엑세스할 수 있습니다.

감사 로그

W&B는 blob storage 특정 감사 로그 외에도 W&B 감사 로그를 사용하는 것이 좋습니다. 후자의 경우 AWS S3 엑세스 로그, Google Cloud Storage 감사 로그 및 Azure blob storage 모니터링을 참조하십시오. 관리 및 보안 팀은 감사 로그를 사용하여 W&B 제품에서 어떤 사용자가 무엇을 하고 있는지 추적하고 특정 사용자에 대한 일부 작업을 제한해야 한다고 판단되면 필요한 조치를 취할 수 있습니다.

사전 서명된 URL은 W&B에서 지원되는 유일한 blob storage 엑세스 메커니즘입니다. 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 허용 목록을 사용하는 것이 좋습니다.

W&B는 개별 /32 IP 어드레스가 아닌 회사 또는 비즈니스 이그레스 게이트웨이에 할당된 CIDR 블록을 사용하는 것이 좋습니다. 개별 IP 어드레스를 사용하는 것은 확장성이 떨어지고 클라우드당 엄격한 제한이 있습니다.

4 - Configure private connectivity to Dedicated Cloud

클라우드 공급자의 보안 사설 네트워크를 통해 전용 클라우드 인스턴스에 연결할 수 있습니다. 이는 AI 워크로드에서 W&B API로의 엑세스와 선택적으로 사용자 브라우저에서 W&B 앱 UI로의 엑세스에도 적용됩니다. 사설 연결을 사용하는 경우 관련 요청 및 응답은 공용 네트워크 또는 인터넷을 통해 전송되지 않습니다.

보안 사설 연결은 곧 전용 클라우드의 고급 보안 옵션으로 제공될 예정입니다.

보안 사설 연결은 AWS, GCP 및 Azure의 전용 클라우드 인스턴스에서 사용할 수 있습니다.

AWS의 AWS Privatelink 사용
GCP의 GCP Private Service Connect 사용
Azure의 Azure Private Link 사용

활성화되면 W&B는 인스턴스에 대한 사설 엔드포인트 서비스를 생성하고 연결할 관련 DNS URI를 제공합니다. 이를 통해 클라우드 계정에서 사설 엔드포인트를 생성하여 관련 트래픽을 사설 엔드포인트 서비스로 라우팅할 수 있습니다. 사설 엔드포인트는 클라우드 VPC 또는 VNet 내에서 실행되는 AI 트레이닝 워크로드에 대해 더 쉽게 설정할 수 있습니다. 사용자 브라우저에서 W&B 앱 UI로의 트래픽에 대해 동일한 메커니즘을 사용하려면 회사 네트워크에서 클라우드 계정의 사설 엔드포인트로 적절한 DNS 기반 라우팅을 구성해야 합니다.

이 기능을 사용하려면 W&B 팀에 문의하십시오.

IP 허용 목록과 함께 보안 사설 연결을 사용할 수 있습니다. IP 허용 목록에 보안 사설 연결을 사용하는 경우 W&B는 AI 워크로드의 모든 트래픽과 가능한 경우 사용자 브라우저의 대부분 트래픽에 대해 보안 사설 연결을 사용하고 권한 있는 위치에서 인스턴스 관리에 IP 허용 목록을 사용하는 것이 좋습니다.

5 - Data encryption in Dedicated cloud

W&B는 각 전용 클라우드에서 클라우드 공급자의 고객 관리 암호화 키 (CMEK) 기능을 사용하여 W&B 관리 데이터베이스 및 오브젝트 스토리지를 암호화하기 위해 W&B 관리 클라우드 네이티브 키를 사용합니다. 이 경우 W&B는 클라우드 공급자의 customer 역할을 하며, W&B 플랫폼을 서비스로 제공합니다. W&B 관리 키를 사용한다는 것은 W&B가 각 클라우드에서 데이터를 암호화하는 데 사용하는 키를 제어하여 모든 고객에게 매우 안전하고 보안이 뛰어난 플랫폼을 제공하겠다는 약속을 강화한다는 의미입니다.

W&B는 각 고객 인스턴스의 데이터를 암호화하기 위해 unique key를 사용하여 전용 클라우드 테넌트 간에 또 다른 격리 계층을 제공합니다. 이 기능은 AWS, Azure 및 GCP에서 사용할 수 있습니다.

2024년 8월 이전에 W&B가 프로비저닝한 GCP 및 Azure의 전용 클라우드 인스턴스는 W&B 관리 데이터베이스 및 오브젝트 스토리지 암호화에 대해 기본 클라우드 공급자 관리 키를 사용합니다. 2024년 8월부터 W&B가 생성한 새로운 인스턴스만 관련 암호화에 대해 W&B 관리 클라우드 네이티브 키를 사용합니다.

AWS의 전용 클라우드 인스턴스는 2024년 8월 이전부터 암호화에 대해 W&B 관리 클라우드 네이티브 키를 사용하고 있습니다.

W&B는 일반적으로 고객이 전용 클라우드 인스턴스에서 W&B 관리 데이터베이스 및 오브젝트 스토리지를 암호화하기 위해 자체 클라우드 네이티브 키를 가져오는 것을 허용하지 않습니다. 조직의 여러 Teams 및 사용자가 다양한 이유로 클라우드 인프라에 엑세스할 수 있기 때문입니다. 이러한 Teams 또는 사용자는 조직의 기술 스택에서 중요한 구성 요소인 W&B에 대한 컨텍스트가 없을 수 있으므로 클라우드 네이티브 키를 완전히 제거하거나 W&B의 엑세스를 취소할 수 있습니다. 이러한 조치는 조직의 W&B 인스턴스에 있는 모든 데이터를 손상시켜 복구 불가능한 상태로 만들 수 있습니다.

AI 워크플로우에 전용 클라우드 사용을 승인하기 위해 조직에서 자체 클라우드 네이티브 키를 사용하여 W&B 관리 데이터베이스 및 오브젝트 스토리지를 암호화해야 하는 경우 W&B는 예외적으로 이를 검토할 수 있습니다. 승인되면 암호화에 대한 클라우드 네이티브 키 사용은 W&B 전용 클라우드의 shared responsibility model을 준수합니다. 전용 클라우드 인스턴스가 활성 상태일 때 조직의 사용자가 키를 제거하거나 W&B의 엑세스를 취소하는 경우 W&B는 그로 인한 데이터 손실 또는 손상에 대해 책임을 지지 않으며 해당 데이터 복구에 대한 책임도 지지 않습니다.