Instiq
第3章 · コンピュート・ストレージ・データベースの保護·v2.0.0·更新 2026/6/3·読了目安 約9分

変更要約: AZ-500 第3章を深掘り(図ja化・比較表/シナリオ/FAQ/ひっかけ/深掘り段落を全節に追加)

3.2ストレージとデータベースの保護

この節の要点

ストレージアカウントのアクセス制御(SAS・キー無効化・Entra 認可)とネットワーク制限、Azure SQL の 認証ファイアウォール透過的データ暗号化(TDE)Always Encrypted を理解します。データ層を多層で守ります。

データは攻撃者の最終目的になりがちです。ストレージと SQL のアクセスを最小化し、暗号化で保存・利用時のデータを守ることが重要です。

3.2.1ストレージと SQL の保護

ストレージアカウント側に SAS(期限/権限/範囲を限定したトークン)・共有キー認証の無効化・Microsoft Entra 認可・ネットワーク制限(ファイアウォール/プライベートエンドポイント)を並べ、Azure SQL 側に Entra 認証・SQL ファイアウォール(許可 IP/VNet)・透過的データ暗号化 TDE(保存時)・Always Encrypted(列単位でアプリ側暗号化)を並べて、データ層を多層で守る様子を示した図。
ストレージと SQL の多層防御
  • ストレージのアクセスSAS(期限/権限/範囲を限定)で限定共有。可能なら共有キー認証を無効化Entra 認可を使う。
  • ストレージのネットワークファイアウォールプライベートエンドポイントで公開アクセスを絞る。
  • SQL の認証/境界Microsoft Entra 認証を推奨し、SQL ファイアウォールで許可 IP/VNet を限定する。
  • SQL の暗号化TDE(保存時にデータベースを暗号化・既定で有効)と Always Encrypted(機密列をクライアント側で暗号化しサーバーに平文を見せない)。
試験ポイント

「期限/範囲限定の共有=SAS」「保存時の DB 暗号化=TDE(既定)」「機密列をサーバーにも見せない=Always Encrypted」「DB は Entra 認証推奨+SQL ファイアウォール」 は AZ-500 で頻出です。TDE は保存時、Always Encrypted は利用時も保護という違いを押さえましょう。

コツ

ストレージの共有キーは強力すぎるため、ユーザー委任 SAS(Entra ID に基づく SAS)やキーの無効化で攻撃面を減らせます。

SAS には 3 種類あります。アカウント SAS はアカウント全体に広く効き、サービス SAS は Blob/Queue などサービス単位、ユーザー委任 SAS は Entra ID の資格情報で署名するため共有キーを使わず、Entra の RBAC とも整合します。共有キー認証は allowSharedKeyAccess=false で無効化でき、その上で Entra 認可(Storage Blob Data Reader 等のロール)に寄せるのが堅牢です。Azure SQL 側では、SQL 認証より Entra 認証 を優先し、サーバー管理者を Entra グループにすると個人アカウントへの依存を避けられます。TDE の保護キーは既定の サービス管理キー から CMK(BYOK) に変更でき、Always Encrypted ではキー(列マスターキー)をクライアント側や Key Vault に置き、SECURE ENCLAVES を使うと暗号化列に対する範囲検索など一部の演算もサーバー側で可能になります。検知面では Microsoft Defender for SQLDefender for Storage が異常アクセスや SQL インジェクションの兆候を検知します。

保護守る対象サーバーは平文を見るか
TDE保存時(ファイル/バックアップ)見る(処理時は復号)
Always Encrypted機密列を端から端まで見ない(クライアント側で復号)
TLS(転送時)通信経路該当外(経路の暗号化)
補足

シナリオ: 外部パートナーに、ある Blob を 1 時間だけ読み取り限定で渡したいが、ストレージキーは渡したくない。→ ユーザー委任 SAS を発行し、読み取り権限・1 時間の有効期限・対象 Blob に範囲を限定します。共有キー認証は無効化したまま、必要なら IP 制限も付けます。

補足

FAQ: Q. TDE があれば Always Encrypted は不要? → A. 目的が違います。TDE は保存時のディスク/バックアップを守りますが、DB 管理者やサーバーは平文を扱えます。DBA にも見せたくない機密列には Always Encrypted を使います。Q. SAS が漏れたら? → A. 関連付けたポリシーの失効や、共有キー/ユーザー委任キーのローテーションで一括無効化できます。

注意

ひっかけ: 「TDE は通信経路(転送時)のデータを暗号化する」は誤りです。TDE は保存時で、転送時は TLS が担当します。また「Always Encrypted を使えばサーバーで自由に検索できる」も基本は誤り(平文を見ないため通常は等価検索など限定。範囲演算には Secure Enclaves が必要)。

3.2.2この節のまとめ

  • ストレージ=SAS・Entra 認可・ネットワーク制限
  • SQL=Entra 認証・ファイアウォール・TDE・Always Encrypted

進捗の記録にはログインが必要です。

理解度チェック

(軽い確認用)

Q1. ストレージ内の特定 Blob へ期限・権限・範囲を限定してアクセスさせたい。何を発行しますか?

Q2. Azure SQL のデータベースを保存時に暗号化する、既定で有効な機能はどれですか?

Q3. クレジットカード番号など機密列を、SQL サーバーにも平文を見せずにクライアント側で暗号化したい。何を使いますか?

理解度を確認第3章「コンピュート・ストレージ・データベースの保護」の問題を解く