回避するためのタグ付けのプラクティス - AWS 規範ガイダンス
タグ付けに一貫性がないタグ内の誤ったデータや機密データ

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

回避するためのタグ付けのプラクティス

オブジェクトまたはインフラストラクチャにタグを付けるときに実装するプラクティスもありますが AWS、回避するプラクティスもあります。

タグ付けに一貫性がない

目的 「」セクションで説明しているように、タグ付けを行わなくても、高レベルの自動化、クリーンアップ、モニタリングを実現することはできません。同様に、タグが不完全または一貫性がない場合、自動化またはモニタリングに必要な情報が完全ではなく、信頼性の低い結果につながります。

タグ付け戦略を使用してすべてのプロジェクトの合計コストを計算するシナリオを想像してみてください。戦略はproof-of-conceptフェーズ (PoC) から始まり、本番稼働フェーズで終了します。プロジェクトの Sales Forecasting P1, D1Pr1 の例と、プロジェクトの販売後メンテナンス P2, D2、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 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 リソースにも適用されます。

したがって、タグで個人情報を使用しないことが非常に重要です。同じ概念は、重要または非公開の情報にも及びます。