피해야 할 태그 지정 방법 - AWS 권장 가이드
일관되지 않은 태그 지정태그의 올바르지 않고 민감한 데이터

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

피해야 할 태그 지정 방법

객체 또는 인프라에 태그를 지정할 때 구현해야 할 관행 AWS이 있지만 피해야 할 관행도 있습니다.

일관되지 않은 태그 지정

목표 단원에서 설명한 대로 태그 지정 없이는 높은 수준의 자동화, 정리 또는 모니터링을 수행할 수 없습니다. 마찬가지로 불완전하거나 일관되지 않은 태그의 경우 자동화 또는 모니터링에 필요한 정보가 완전하지 않아 신뢰할 수 없는 결과가 발생합니다.

태그 지정 전략을 사용하여 모든 프로젝트의 총 비용을 계산하는 시나리오를 상상해 보세요. 전략은 proof-of-concept 단계(PoC)에서 시작하여 프로덕션 단계에서 끝납니다. 프로젝트 판매 예측 P1, D1 및 Pr1 예제와 프로젝트 판매 후 유지 관리 P2, D2 및 Pr2 예제에 대해 데이터 및 리소스에 태그가 적용된 다음 시나리오를 고려하세요.

판매 예측

예제 P1: PoC 프로젝트(도메인 및 타임스탬프 누락).

env: "poc"
project: "sales forecasting"

예제 D1: 개발 단계(도메인 누락).

env: "dev"
project: "sales forecasting"
timestamp: 20210505T12:34:55

예제 Pr1: 프로덕션 단계(모든 값이 존재).

env: "prod"
project: "sales forecasting"
domain: "machine learning"
timestamp: 20210505T12:34:55

프로젝트 판매 예측의 경우:

  • 예제 P1은 객체의 도메인 또는 타임스탬프를 언급하지 않습니다.

  • 예제 D1은 프로젝트의 도메인도 언급하지 않습니다.

  • 예제 Pr1에는 필요한 모든 데이터가 있습니다.

예제 P1 및 D1은 도메인이 정의되지 않았기 때문에 계획에 대한 잘못된 보고 또는 추정을 초래합니다.

판매 후 유지 관리

예제 P2: PoC 프로젝트(모든 태그 누락).

예제 D2: 개발 단계(프로젝트 누락).

env: "dev"
domain: "machine learning"
timestamp: 20210505T12:34:55

예제 Pr2: 프로덕션 단계(모든 값 존재).

env: "prod"
project: "post sales maintenance"
domain: "machine learning"
timestamp: 20210505T12:34:55

프로젝트 판매 후 유지 관리의 경우:

  • 예제 P2에는 정보가 없으므로 추적할 수 없습니다.

  • 예제 D2는 프로젝트 이름을 언급하지 않으므로 추적할 수 없습니다.

  • 예제 Pr2에는 필요한 모든 데이터가 있습니다.

예제 P2 및 D2는 누락되거나 일관되지 않은 태그로 인해 잘못된 보고, 계획 미달 또는 과소 보고를 초래합니다.

따라서 태그 지정 전략을 일관되게 구현하는 것이 중요합니다.

태그의 올바르지 않고 민감한 데이터

태그 지정은 잘못되거나 민감한 정보 또는 비공개 정보와 함께 사용하는 경우 비생산적일 수 있습니다. 태그가 잘못되면 잘못된 결과가 발생할 수 있습니다. 개인 식별 정보(PII)와 같은 민감한 데이터가 포함된 태그를 사용하면 고객과 직원의 보안이 위험에 처할 수 있습니다.

태그의 잘못된 정보

태그 지정 전략을 사용하여 각 도메인 또는 부서의 총 비용을 계산하는 시나리오를 가정해 보겠습니다. 방금 데이터 수집 단계를 마쳤으며 기계 학습으로 전환하고 있습니다. 다음 예제에는 프로젝트의 이전 단계에서 복사된 사용자 지정 태그가 포함되어 있습니다.

env: "development"
project: "sales prediction"
domain: "data ingestion"
timestamp: 20210505T12:34:55

도메인의 레이블이 올바른 도메인인 대신 data ingestion 이전 프로젝트 단계에서 로 잘못 지정되었습니다machine learning. 이제 data ingestion 도메인에 대한 보고서에 더 높은 비용, 시간 범위 및 리소스 할당이 표시됩니다. machine learning 도메인에는 해당 보고서에 대한 더 낮은 값이 표시됩니다. 이로 인해 잘못된 계획, 예산 할당 및 기한 추정치가 발생합니다.

기능 시스템에는 올바른 태그가 있어야 합니다.

태그의 민감한 정보

AWS 는 객체에서 PII를 식별하기 위한 여러 도구를 제공합니다. 이러한 도구에는 Amazon Amazon Macie와 개인을 식별하는 데 사용할 수 있는 데이터를 찾기 위한 AWS Glue 민감한 데이터 감지가 포함됩니다. 그러나 PII 또는 민감한 데이터를 태그에 사용하지 않는 것이 중요합니다.

PII가 수정되거나 익명화된 Amazon S3의 파일의 다음 예를 생각해 보세요.

{
  firstName: "67A1790DCA55B8803AD024EE28F616A2",
  lastName: "DRG54654DFHJGDYYRD",
  age: 21,
  city : "Frankfurt",
  probability_of_purchase: 48.858093,
  veggieName: "broccoli",
  creditcard: false
}

고객 이름과 성이 해시된 것을 확인할 수 있습니다. 그러나이 예제에서는 레코드에 다음과 같은 사용자 지정 태그가 있습니다.

owner: "Company XYZ"
about: "John Doe"
contact: "johnthegreat@email.com"
timestamp: 20210505T12:34:55

이 경우 파일 자체에 PII가 포함되어 있지 않지만 태그에는 민감한 정보가 포함되어 있습니다. 이렇게 하면 파일 또는 객체를 공유하거나 전송할 때 메타데이터도 공유하거나 전송할 수 있으므로 정보 유출 가능성이 높아집니다. 이는 데이터베이스, 테이블, 작업 및 함수와 같은 다른 AWS 리소스에도 적용됩니다.

따라서 태그에 개인 정보를 사용하지 않는 것이 매우 중요합니다. 동일한 개념이 중요한 정보 또는 비공개 정보로 확장됩니다.