暗号鍵の不適切な管理は、さまざまなセキュリティ侵害の原因となります。組織は、重要なデータ リソースについて、プラットフォームマネージド キーに依存するべきではありません。

物理メディアの盗難は、攻撃者が機密情報にアクセスする際の一般的な手段です。

デフォルトでは、Azure SQL データベースは Transparent Data Encryption (TDE) を使用して、保存データを暗号化および保護します。

Azure SQL データベースの TDE を無効にすると、データが盗まれる可能性があります。

例 1: 次の例は、データを暗号化しない Azure SQL データベースを定義する Terraform 構成を示しています。

resource "azurerm_mssql_database" "aztf008-tp-01" {
  name           = "aztf008-db-d"
  ... 
  sku_name       = "DW100c"
  ...
  transparent_data_encryption_enabled = false
}

実装上の欠陥、構成ミス、および侵害されたキーといった問題が、単一層の暗号化では機密性の高いデータを完全に保護することができない原因となっています。組織は、機密性の高いデータを保護し、セキュリティ設計に単一障害点を生まない、多層防御アプローチを採用する必要があります。

実装上の欠陥、構成ミス、および侵害されたキーといった問題が、単一層の暗号化では機密性の高いデータを完全に保護することができない原因となっています。組織は、機密性の高いデータを保護し、セキュリティ設計に単一障害点を生まない、多層防御アプローチを採用する必要があります。

既知のソフトウェアの脆弱性にタイムリーにパッチを適用するソフトウェア自動アップグレードは無効になっています。

クラウド サービスは通常、サービスのスケーラビリティを促進し、コンテンツをより速く配信し、ボリューム攻撃の影響を軽減するために、キャッシュ、レプリケーション、負荷分散などの技術を使用します。可用性機能が無効になっているか、誤って構成されていると、サービスのパフォーマンスが低下しますが、多くの場合、トラフィックの急増やハードウェア障害などの極端なイベントが発生するまで、すぐには影響が現れません。

Azure にはいくつかの暗号化オプションが用意されており、それぞれに具体的な利点と制限事項があります。たとえば、Azure ストレージのサーバー側暗号化 (SSE) は、デフォルトで、コンピューティング リソースを使用せずに暗号化を実行しますが、一時ディスクやキャッシュは暗号化しません。また、コンピューティング インスタンスからストレージへのデータ フローも保護しません。Azure Disk Encryption (ADE) は、一時ディスクとキャッシュの両方、およびストレージに流れるデータを暗号化しますが、コンピューティング リソースを多く消費します。

暗号鍵の不適切な管理は、さまざまなセキュリティ侵害の原因となります。組織は、重要なデータ リソースについて、プラットフォームマネージド キーに依存するべきではありません。

暗号鍵の不適切な管理は、さまざまなセキュリティ侵害の原因となります。組織は、重要なデータ リソースについて、プラットフォームマネージド キーに依存するべきではありません。

データのバックアップは、元のデータと同等レベルの保護で十分なアセットとして見過ごされがちです。

バックアップが暗号化されていないと、潜在的な攻撃者によるバックアップ データへのアクセスが可能な状態になります。

デフォルトでは、Azure SQL 仮想マシンの自動バックアップ設定は、データ バックアップの暗号化を強制しません。

例 1: 次の例は、バックアップ データの暗号化を強制しない、Azure SQL 仮想マシンの自動バックアップ設定を定義する Terraform 構成を示しています。

resource "azurerm_mssql_virtual_machine" "aztf009-tn-03" {
  virtual_machine_id               = data.azurerm_virtual_machine.example.id
  ...
  auto_backup {
    retention_period_in_days = 1
    storage_blob_endpoint = ""
    storage_account_access_key = azurerm_storage_account.example.primary_access_key
  }
}

暗号鍵の不適切な管理は、さまざまなセキュリティ侵害の原因となります。組織は、重要なデータ リソースについて、プラットフォームマネージド キーに依存するべきではありません。

実装上の欠陥、構成ミス、および侵害されたキーといった問題が、単一層の暗号化では機密性の高いデータを完全に保護することができない原因となっています。組織は、機密性の高いデータを保護し、セキュリティ設計に単一障害点を生まない、多層防御アプローチを採用する必要があります。

暗号鍵の不適切な管理は、さまざまなセキュリティ侵害の原因となります。組織は、重要なデータ リソースについて、プラットフォームマネージド キーに依存するべきではありません。

Azure にはいくつかの暗号化オプションが用意されており、それぞれに具体的な利点と制限事項があります。たとえば、Azure ストレージのサーバー側暗号化 (SSE) は、デフォルトで、コンピューティング リソースを使用せずに暗号化を実行しますが、一時ディスクやキャッシュは暗号化しません。また、コンピューティング インスタンスからストレージへのデータ フローも保護しません。Azure Disk Encryption (ADE) は、一時ディスクとキャッシュの両方、およびストレージに流れるデータを暗号化しますが、コンピューティング リソースを多く消費します。

暗号鍵の不適切な管理は、さまざまなセキュリティ侵害の原因となります。組織は、重要なデータ リソースについて、プラットフォームマネージド キーに依存するべきではありません。

脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

Apache Ivy の自動依存関係管理システムを使用すると、ユーザーは、特定の依存関係を一覧表示する代わりに、動的リビジョンと呼ばれるバージョン ステータスを指定できます。攻撃者が依存関係リポジトリを侵害したり、ビルド システムをだまして攻撃者の制御下でリポジトリから依存関係をダウンロードさせたりできる場合、侵害された依存関係をサイレントにダウンロードして実行するのにビルド システムが必要とするのは、動的リビジョンの指定子だけです。セキュリティ リスクに加え、動的リビジョンは、コード品質の面でリスクの要素ももたらします。動的リビジョンは、ソフトウェアのセキュリティと安定性を、ソフトウェアが使用する依存関係を開発およびリリースするサードパーティの管理下に置きます。

ビルド時に、Ivy はリポジトリに接続し、リストされたステータスに一致する依存関係を取得しようとします。

Ivy は、次の動的リビジョンの指定子を受け入れます。

- latest.integration: 依存関係モジュールの最新リビジョンを選択します。
- latest.[any status]: 少なくとも指定されたステータスを持つ依存関係モジュールの最新リビジョンを選択します。たとえば、latest.milestone は最新バージョン (マイルストーンまたはリリース) を選択し、latest.release は最新のリリースのみを選択します。
- + で終わるリビジョン: 依存関係モジュールの最新のサブリビジョンを選択します。たとえば、依存関係がリビジョン 1.0.3、1.0.7、および 1.1.2 にある場合、1.0.+ と指定されたリビジョンは 1.0.7 を選択します。
- バージョンの範囲: < や > などの範囲の数学記号を使用して、バージョンの範囲を指定できます。

例 1: 次の設定エントリは、クローバー コンポーネントの最新リリース バージョンを取得するように Ivy に指示します。

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

リポジトリが危険にさらされると、攻撃者が動的基準を満たすバージョンをアップロードするだけで、悪意のあるバージョンの依存関係を Ivy にダウンロードさせることができます。