セキュリティ・コンプライアンスと設計運用（技術的側面）

1. 暗号化（At Rest / In Transit）
1-1. Azure Storage / SQL Database での暗号化
暗号化方式

設定例・推奨値

Azure SQL Database: Transparent Data Encryption (TDE)

Azure Storage: AES256 (既定で有効)

補足

SQL Database や Managed Instance は TDE を有効化すると、バックアップも自動的に暗号化される

コスト面

TDE などの標準暗号化機能は追加コストなし

キー管理

設定例・推奨値

Service-managed key (Microsoft 管理)

Customer-managed key (BYOK) in Key Vault

補足

機密度が高い場合は BYOK を推奨

自社でキーを管理することで第三者によるデータの勝手な復号を防止（“補完的措置”）

コスト面

Key Vault Premium (HSM) を利用する場合は Premium SKU の費用がかかる

キー長

設定例・推奨値

RSA 2048 以上（推奨：3072 もしくは 4096）

補足

HSM バックエンドでは最大鍵長等の制限を事前に確認

コスト面

鍵長自体で大きくコストは変わらないが、長い鍵は処理負荷が増えパフォーマンスに若干影響

バックアップ暗号化

設定例・推奨値

SQL DB / MI のバックアップも自動暗号化 (TDE)

補足

追加の設定は不要だが、Long-term backup の保存期間はコストに反映される

コスト面

例: 長期バックアップを Azure Backup で 7 年間保持するとストレージ容量コストが増大するため、必要期間を精査

▸ よりセキュアな実装例：Always Encrypted（SQL Database）

内容

アプリケーションレベルで列単位の暗号化を行い、サーバーサイドでデータの平文を扱わない

マイナンバーやクレジットカードなど、さらに厳格な機微情報を扱う場合に検討

コスト面

SQL DB の標準機能で追加課金はなし

ただし、実装・運用における工数増に留意

1-2. Key Vault (KMS) の導入
Key Vault 名

設定例・推奨値

<Project>-keyvault-prod など、一貫したネーミングルール

補足

企業・プロジェクトのネーミング規則に合わせる

コスト面

Key Vault 自体は基本利用料なし（トランザクション課金）

SKU / パフォーマンス層

設定例・推奨値

Standard または Premium (HSM)

補足

Premium は FIPS 140-2 レベル 3 相当の HSM バックエンドを利用可能

コスト面

Premium SKU は月額費用が割高

高セキュリティが必要な機密データには検討価値あり

アクセス構成

設定例・推奨値

RBAC (Azure role-based) を基本とし、必要に応じて従来の Access Policy を併用

補足

新しい Key Vault は RBAC ベース管理が推奨

細かな権限管理が必要な場合、Access Policy との組み合わせを検討

コスト面

RBAC 自体で追加コストは発生しない

主なキー操作

設定例・推奨値

Generate / Import (BYOK), Wrap / Unwrap, Sign / Verify

補足

「最小権限原則」で不要な操作を許可しない

BYOK はオンプレ HSM で生成した鍵を Azure にインポートするケース

コスト面

Key Vault はキー操作（トランザクション）毎に課金

キーローテーション短縮はトランザクション増によるコスト増要因

キー回転（ローテーション）

設定例・推奨値

自動ローテーションポリシーを 12 か月ごとなどで設定

補足

PCI DSS 等では 1 年に 1 回以上のキー更新が推奨

コスト面

ローテーション頻度が高いほど Key Operation が増加し、費用に影響

監査ログ

設定例・推奨値

Diagnostic Settings → Log Analytics / Event Hub へ送信

補足

すべての Key 操作を監査ログとして中央集約

インシデント発生時の追跡に必須

コスト面

Log Analytics はデータ量・保存期間に応じて従量課金

容量最適化設定やデータライフサイクル管理が必要

▸ よりセキュアな実装例：Key Vault Premium + BYOK + Double Encryption

内容

HSM バックエンド利用 + 暗号化済みのキーを持ち込み（BYOK）で Microsoft に平文鍵を渡さない

コスト面

Key Vault Premium の基本料金 + トランザクションコスト

BYOK の鍵管理工数も考慮

1-3. 通信暗号化（SSL/TLS 等）
TLS バージョン

設定例・推奨値

TLS 1.2 または TLS 1.3

補足

古い TLS/SSL バージョンはリスクが高く無効化推奨

コスト面

Azure App Service / Application Gateway などでの TLS 終端に追加費用はない

SSL 証明書の更新コストは別途発生

Azure App Service

設定例・推奨値

HTTPS Only を On

カスタムドメイン + SSL 証明書

補足

HTTP を自動リダイレクトし、常時 HTTPS 化

コスト面

App Service で App Service Certificate を購入する場合、証明書費用が追加

Application Gateway (WAF)

設定例・推奨値

フロントエンドリスナーで最低 TLS 1.2

WAF (Prevention モード)

補足

OWASP Top10 攻撃対策

クライアント認証を有効にすることでさらにセキュア

コスト面

Application Gateway の従量課金 + WAF 機能有効化の追加費用

スケールアウト状況に応じてコストが上昇

VPN / ExpressRoute

設定例・推奨値

VPN ゲートウェイで IPsec/IKE を利用

専用線連携が必要な場合は ExpressRoute を検討

補足

オンプレ環境との接続を想定したセキュア通信経路

コスト面

Site-to-Site VPN Gateway：月額 + 帯域従量課金

ExpressRoute：初期費用・月額費用ともに高め

▸ よりセキュアな実装例：Client Certificate Authentication

内容

AppGW や API Management などでクライアント証明書による相互 TLS を実装

リクエスト元を特定し、不正アクセスを厳格に排除

コスト面

証明書の発行・管理コストが増える

大規模ユーザーには運用負荷も高い

 

2. アクセス制御 (IAM / RBAC)
2-1. Entra ID（旧 EntraID）による認証基盤
ディレクトリ名・ドメイン

設定例・推奨値

<organization>.onmicrosoft.com + カスタムドメイン

補足

組織の正式ドメインを追加することでブランド管理・利便性向上

コスト面

EntraID Free / Microsoft 365 / EMS などのライセンス構成で機能・費用が変動

多要素認証 (MFA)

設定例・推奨値

条件付きアクセスポリシーで全ユーザーに MFA を強制

管理者アカウントは常時 MFA

補足

特権アカウントのハイジャック対策に必須

コスト面

EntraID Premium P1/P2 が必要

無料版でも MFA は限定的に利用可能だが、条件付きアクセスは有料版が必要

条件付きアクセス (Conditional Access)

設定例・推奨値

リスクベースポリシー (ユーザーリスク / サインインリスク)

ロケーションベース (ジオフィルタリング)

補足

国外からの不正アクセス防止、未登録デバイスからのアクセス制限など

コスト面

EntraID Premium P2 の機能を利用する場合、追加ライセンスが必要

▸ よりセキュアな実装例

内容

EntraID Identity Protection でリスク検知を高度化し、リスクレベルに応じて MFA 再要求やアカウントロックダウンを自動化

Just-in-time (JIT) で特権アカウントを付与し、通常時は管理権限を付与しない

コスト面

EntraID Premium P2 が必要

2-2. Azure RBAC (Role-Based Access Control)
ロール定義

設定例・推奨値

組み込みロール (Owner / Contributor / Reader など)

カスタムロール（最小権限）

補足

不要な操作権限を付けない“Least Privilege”を徹底

コスト面

Azure RBAC 自体に追加コストはなし

スコープ階層

設定例・推奨値

Management Group → Subscription → Resource Group → Resource

補足

大規模組織では多段階管理でガバナンスを実現

コスト面

スコープの階層構造自体は無料

ただし管理工数が増える可能性あり

特権アクセス管理

設定例・推奨値

Privileged Identity Management (PIM)

Just-In-Time アクセス

補足

必要なときだけ特権ロールを有効化し、監査ログを自動取得

コスト面

PIM 利用には EntraID Premium P2 が必須

▸ よりセキュアな実装例

内容

テナント全体管理（Global Admin）やセキュリティ管理、ユーザー管理、リソース管理などロールを明確に分割

リソース単位でカスタムロールを作成し、意図しない操作（例：VNet の削除）を防ぐ

コスト面

RBAC は無料だが、PIM をフル活用する場合は EntraID Premium P2 が必要

2-3. 監査ログ
EntraID Audit Logs

設定例・推奨値

90 日以上保管（Log Analytics 等へ転送して長期保存）

補足

アカウント操作履歴やロール変更履歴など、証跡として必須

コスト面

Log Analytics のデータ量に応じて従量課金

古いログはコールド / アーカイブストレージに移動してコスト削減可能

Azure Activity Logs

設定例・推奨値

Resource Group / Subscription 単位で Log Analytics に送信

補足

VM 作成・削除、ネットワーク変更など管理操作の追跡に利用

コスト面

データ量が多いとコスト増大

必要に応じてフィルタ設定・短期保持を検討

Azure Monitor

設定例・推奨値

Diagnostic Settings で Key Vault / Storage / SQL などの操作ログを取得

補足

重要リソースの診断ログを取りこぼさないように全サブスクリプションで設定確認

コスト面

Log Analytics / Event Hub への転送コスト、ストレージコストに注意

▸ よりセキュアな実装例：Azure Sentinel (SIEM)

内容

ログを統合管理し、脅威検知ルールや Playbook を設定

コスト面

Sentinel は GB 単位で課金 + オートスケール

大量のログ保管にはライフサイクル管理でコスト最適化

 

3. Azure Security Center / Defender for Cloud
プラン

設定例・推奨値

Free プラン（基本的な脆弱性評価のみ）

Microsoft Defender プラン（有料）

補足

本番や機密データ環境は有料プラン推奨

脅威検知やコンプライアンス評価が可能

コスト面

リソース数やデータ量に応じた従量課金

VM、Kubernetes、SQL など対象リソースを増やすとコスト上昇

脆弱性スキャン

設定例・推奨値

VM やコンテナ イメージを定期スキャンし、OS パッチやライブラリの更新を促す

補足

ハイブリッド環境（オンプレ / 他クラウド）もサポート

コスト面

Defender プランに含まれるスキャン機能は追加従量課金あり

サードパーティ製品導入よりは割安な場合も

コンプライアンス アセスメント

設定例・推奨値

ISO27001, PCI DSS, NIST SP 800-53, HIPAA など各種規格への対応を評価

補足

セキュリティスコアや推奨事項を確認し、継続的に設定を改善

コスト面

評価対象リソース数が増えると検査コストが上昇

一元管理で監査工数を削減可能

セキュリティ アラートと修復ガイド

設定例・推奨値

SIEM (Azure Sentinel) やメール通知でリアルタイム検知

Playbook (Logic Apps) で自動修復

補足

攻撃検知後、自動で NSG のルール変更や Key Vault 認証停止などが可能

コスト面

Sentinel、Logic Apps の実行回数に応じて課金

自動化で運用工数削減可能だが、Pay-as-you-go コストは増える可能性

▸ よりセキュアな実装例

内容

Security Posture Management: Defender for Cloud + Azure Policy を組み合わせ、違反リソースを自動修正（Enforce）

Zero Trust アーキテクチャ: Identity-based segmentation（RBAC / MFA / Conditional Access）+ ネットワークマイクロセグメンテーション（NSG / Firewall）

コスト面

高度な機能によりコスト増加の可能性

ただしセキュリティの強化と運用負荷軽減のバランスを検討

 

4. コストに対する総合的な最適化アプローチ
スモールスタート + 必要な部分のみ Premium 機能

Key Vault の HSM バックエンドを全てではなく、最も機密度の高いデータにのみ BYOK + HSM を適用

Defender for Cloud もまずは重要リソースに有料プランを適用し、効果確認後に範囲拡張

ログのライフサイクル管理

Log Analytics の課金はデータ量と保存期間が要因

30 日はホットストレージ、その後コールド / アーカイブに移動してコスト削減

Sentinel も同様に、使用頻度の低い過去ログは安価なストレージへ移行

ライセンスプランの一元化

EntraID Premium P2、Microsoft 365 E5、EMS E5 などをパッケージで導入すると、単体ライセンスより割安となる場合あり

PIM、Identity Protection、Defender for Endpoint など高度な機能を包括的に利用し、セキュリティを高めながらコストを最適化

利用監視と運用の最適化

Azure Cost Management などでセキュリティ対策に伴う追加コストを可視化し、ROI を評価

リスクアセスメントとコスト/効果のバランスを常に検証し、過度に厳格すぎない運用を継続的に改5. まとめ：よりセキュアな実装とコストバランスの両立

暗号化

At Rest: Azure の既定暗号化 + BYOK (Key Vault) + (必要に応じて HSM Premium)

In Transit: TLS 1.2/1.3、WAF (Prevention モード)、VPN/IPsec

機密度によって段階的に実装し、不要に高コストな仕組みを全域に適用しない。

アクセス制御・監査ログ

EntraID Premium で MFA、条件付きアクセス、PIM を活用し特権アカウントを最小化。

監査ログは Log Analytics + Azure Sentinel で集中管理し、ライフサイクル管理を徹底してストレージコストを制御。

Defender for Cloud

脆弱性評価、コンプライアンスチェック、リアルタイム脅威検出を有料プランで有効化。

まず重要システムに導入 → 効果を見つつ全社展開 → ログやアラートの運用を自動化（Playbook 活用）して工数削減とセキュリティ強化を両立。

コスト最適化

HSM や PIM、SIEM (Sentinel) は高度なセキュリティを得られる一方、月額・従量課金も増大。

リスク分析を基に、真に守るべきデータやリソースに投資を集中することで、コストパフォーマンスを最大化。

最終的には、法規制・コンプライアンス（国内個人情報保護法、GDPR、ISO/NIST 等）に則しつつ、自社ビジネスが求めるセキュリティレベルを満たすための最適なバランスを探ることが重要です。上記のパラメータシートレベルの設計項目とコスト見合いを検討しながら、段階的にセキュリティ実装を拡充・運用改善していくことで、安全性と経済性の両立が実現できます。

 

5. まとめ：よりセキュアな実装とコストバランスの両立
暗号化

At Rest: Azure の既定暗号化 + BYOK (Key Vault) + (必要に応じて HSM Premium)
In Transit: TLS 1.2/1.3、WAF (Prevention モード)、VPN/IPsec
機密度によって段階的に実装し、不要に高コストな仕組みを全域に適用しない。
アクセス制御・監査ログ

EntraID Premium で MFA、条件付きアクセス、PIM を活用し特権アカウントを最小化。
監査ログは Log Analytics + Azure Sentinel で集中管理し、ライフサイクル管理を徹底してストレージコストを制御。
Defender for Cloud

脆弱性評価、コンプライアンスチェック、リアルタイム脅威検出を有料プランで有効化。
まず重要システムに導入 → 効果を見つつ全社展開 → ログやアラートの運用を自動化（Playbook 活用）して工数削減とセキュリティ強化を両立。
コスト最適化

HSM や PIM、SIEM (Sentinel) は高度なセキュリティを得られる一方、月額・従量課金も増大。
リスク分析を基に、真に守るべきデータやリソースに投資を集中することで、コストパフォーマンスを最大化。
最終的には、法規制・コンプライアンス（国内個人情報保護法、GDPR、ISO/NIST 等）に則しつつ、自社ビジネスが求めるセキュリティレベルを満たすための最適なバランスを探ることが重要です。上記のパラメータシートレベルの設計項目とコスト見合いを検討しながら、段階的にセキュリティ実装を拡充・運用改善していくことで、安全性と経済性の両立が実現できます。

​

​

​参照→ブログ

​

​