More than 3 years have passed since last update.

Azure Well-Architected Review の日本語訳～セキュリティ編～(2021 年 2 月時点)

Azure

Posted at 2021-03-08

はじめに

Azure ワークロードの品質向上に使用できる基本原則として「 Azure Well-Architected Framework 」と呼ばれるものがあります。 Azure Well-Architected Framework は 「コストの最適化」「オペレーショナルエクセレンス」「パフォーマンス効率」「信頼性」「セキュリティ」 の 5 つの柱で構成され、それぞれに細かな指針や確認事項が示されています。

また、自身の Azure 環境がどの程度 Well-Architected Framework に準じているかを評価するための仕組みとして「Azure Well-Architected Review」があります。これは、以下のリンク先で選択肢にチェックを入れていくだけで、誰でも利用できます。

Azure Well-Architected Review

2021 年 2 月現在、Azure Well-Architected Review は英語でのみ提供されています。項目数が多く設問ごとに頭の中で翻訳していると時間がかかると思い、現在のチェックリストを一通り日本語訳してみました。

本記事では 5 つの柱の中から 「セキュリティ」 を取り上げます。翻訳に自信のない箇所や意訳した箇所については補足で記述していますが、より適切な訳し方があればコメントいただけると幸いです。

Have you done a threat analysis of your workload?

ワークロードの脅威を分析したか？

Threat modeling processes are adopted, identified threats are ranked based on organizational impact, mapped to mitigations and communicated to stakeholders.

There's a process to track, triage and address security threats in the application development cycle.

Timelines and processess are established to deploy mitigations (security fixes) for identified threats.

Security requirements are defined for this workload.

Threat protection was addressed for this workload.

Security posture was evaluated with standard benchmarks (CIS Control Framework, MITRE framework etc.).

Business critical workloads, which may adversely affect operations if they are compromised or become unavailable, were identified and classified.

None of the above.

脅威のモデリングプロセスが適用され、特定された脅威は組織への影響に基づき順位付けされ、緩和策にマップされ、関係者へ伝達されている。
アプリケーション開発サイクルにおいて、セキュリティの脅威を追跡、選別、対処するためのプロセスがある。
特定された脅威を緩和策(セキュリティ FIX のような)をデプロイするためのタイムラインやプロセスが確立されている。
ワークロードでセキュリティ要件が定義されている。
ワークロードで脅威への防御策が対処済である。
セキュリティ体制が CIS Control や MITRE といった標準的なベンチマークによって評価されている。
危険にさらされたり利用できなくなると運用に悪影響のあるビジネス上で重要なワークロードが特定、分類されている。
上記いずれでもない。

What considerations for compliance and governance did you make in this workload?

ワークロードにおいて、コンプライアンスとガバナンスのために何を考えるか？

Regulatory and governance requirements of this workload are known and well understood.

Landing Zone concept is implemented for this workload using Azure Blueprints and/or Azure Policies.

Azure Policies are used to enforce and control security and organizational standards.

Root management group is used and any changes that are applied using this group are carefully considered.

Compliance for this workload is systematically monitored and maintained. Regular compliance attestations are performed.

External or internal audits of this workload are performed periodically.

Security plan for this workload was developed and is maintained.

Best practices and guidelines, based on industry recommendations, are reviewed and applied proactively.

Attacker vs. defender costs are considered when implementing defenses. Easy and cheap attack methods are always prevented.

Attacker access containment is considered when making investments into security solutions.

None of the above.

ワークロードの規制とガバナンスの要件が知られ、十分に理解されている。
ワークロードで Azure Blueprints や Azure Policies を使いランディングゾーンのコンセプトが実装されている。
セキュリティと組織標準を施行、制御するために Azure Policies が使われている。
ルート管理グループが使われ、このグループを使って適用されるあらゆる変更は慎重に検討されている。
ワークロードのコンプライアンスはシステマチックに監視・維持されている。定期的なコンプライアンス認証が実施されている。
ワークロードで外部または内部監査が定期的に行われている。
ワークロードのセキュリティ計画が作成・維持されている。
業界の推奨事項に基づくベストプラクティスやガイドラインがレビューされ、積極的に適用されている。
防御策を実装する際は攻撃者と防御者のコストが検討されている。簡単で手軽な攻撃方法は常に防がれている。
セキュリティソリューションに投資する際には、攻撃者のアクセス封鎖が検討されている。
上記いずれでもない。

What practices and tools have you implemented as part of the development cycle?

開発サイクルの一部として実装したプラクティスやツールは何か？

A list of dependencies, frameworks and libraries used by this workload is maintained and updated regularly

Framework and library updates are included into the workload lifecycle.

Technologies and frameworks used in this workload are fully understood, including their vulnerabilities.

Security updates to VMs are applied in a timely manner, and strong passwords exist on those VMs for any local administrative accounts that may be in use.

All cloud services used by this workload are identified and it is understood how to configure them securely.

Personally identifiable information (PII) is detected and removed/obfuscated automatically for this workload, including application logs.

Azure Tags are used to enrich Azure resources with operational metadata.

Elevated security capabilities such as dedicated Hardware Security Modules (HSMs) or the use of Confidential Computing was implemented or considered implementing?

None of the above.

ワークロードで使われている依存関係やフレームワーク・ライブラリの一覧が維持され、定期的に更新されている。
フレームワークやライブラリのアップデートがワークロードのライフサイクルに含まれている。
ワークロードで使われている技術やフレームワークが脆弱性も含めて十分に理解されている。
VM のセキュリティアップデートはタイムリーな方法で適用され、利用されている全てのローカル管理者アカウントに強力なパスワードが存在する。
ワークロードで使われている全てのクラウドサービスが識別され、どのようにセキュアに構成するかを理解されている。
アプリケーションログも含め、ワークロードで個人を識別可能な情報が検知されると自動で削除か難読かされる。
Azure リソースに運用メタデータを付与するため、 Azure Tags が使われている。
占有のハードウェアセキュリティモジュールやコンフィデンシャルコンピューティングの使用といった高度なセキュリティ機能が実装もしくは実装を検討されているか？
上記いずれでもない。

補足 1

～timely manner～ 直訳だとイマイチなのですが、良い訳が浮かばなかったためそのままにしています。

Have you adopted a formal secure DevOps approach to building and maintaining software?

ソフトウェアを構築維持するために、正式でセキュアな DevOps のアプローチに適合しているか？

Formal DevOps approach to building and maintaining software in this workload was adopted.

DevOps security guidance based on industry lessons-learned, and available automation tools (OWASP guidance, Microsoft toolkit for Secure DevOps etc.) is leveraged.

Gates and approvals are configured in DevOps release process of this workload.

Security team is involved in planning, design and the rest of DevOps process of this workload.

Deployments are automated and it's possible to deploy N+1 and N-1 version (where N is the current production).

Code scanning tools are integrated as part of the continuous integration (CI) process for this workload and cover also 3rd party dependencies.

Credentials, certificates and other secrets are managed in a secure manner inside of CI/CD pipelines.

Branch policies are used in source control management, main branch is protected and code reviews are required.

Security controls are applied to all self-hosted build agents used by this workload (if any).

CI/CD roles and permissions are clearly defined for this workload.

None of the above.

ワークロードにおいて、ソフトウェアを構築維持するために正式な DevOps のアプローチに適合している。
業界の知見に基づく DevOps のセキュリティガイダンス(OWASP guidance など)や利用可能な自動化ツール(Microsoft toolkit for Secure DevOps など)が活用されている
ワークロードの DevOps リリースプロセスにおいて、ゲートや承認が構成されている。
ワークロードの DevOps の計画、設計、休止のプロセスにおいて、セキュリティチームが関与している。
デプロイが自動化され、プロダクション環境にデプロイされている現行バージョンに対して 1 世代前後のバージョンがデプロイ可能である。
ワークロードの CI プロセスの一部としてコードスキャニングが統合され、3rd party の依存関係もカバーしている。
クレデンシャルや証明書、その他のシークレットは CI/CD パイプライン内でセキュアな方法で管理されている。
ソース管理においてブランチポリシーが使われており、main ブランチは保護されコードレビューが要求される。
ワークロードで使われている全ての自己ホスト統合型ビルドエージェントにセキュリティ統制が適用されている。
ワークロードで CI/CD のロールや権限が明確に定義されている。
上記いずれでもない。

補足 2

～cover also～「対応している」ぐらいの意訳でもいいかもしれないです。

Is the workload developed and configured in a secure way?

ワークロードはセキュアな方法で開発、構成されているか？

Cloud services are used for well-established functions instead of building custom service implementations.

Detailed error messages and verbose information are hidden from the end user/client applications. Exceptions in code are handled gracefully and logged.

Platform specific information (e.g. web server version) is removed from server-client communication channels.

CDN (content delivery network) is used to separate the hosting platform and end-users/clients.

Application configuration is stored using a dedicated configuration management system (Azure App Configuration, Azure Key Vault etc.)

Access to data storage is identity-based, whenever possible.

Authentication tokens are cached securely and encrypted when sharing across web servers.

There are controls in place for this workload to detect and protect from data exfiltration.

None of the above.

クラウドサービスでは、カスタムサービスの実装を組み込む代わりに確立された機能が使われている。
詳細なエラーメッセージや情報はエンドユーザーやクライアントアプリケーションからは隠れている。コードの例外は上手く制御、記録されている。
Web サーバーのバージョンといったプラットフォーム固有の情報はサーバー-クライアント間の通信チャネルからは削除されている。
ホスティング環境とエンドユーザー/クライアントを分離するため CDN が使われている。
Azure App Configuration や Azure Key Vault といった占有の構成管理システムを使用し、アプリケーションの構成が蓄積されている。
デートストレージへは ID ベースで可能な時にいつでもアクセスできる。
認証トークンが Web サーバー間で共有される際は、セキュアにキャッシュされ暗号化されている。
ワークロードでデータの漏洩を検出、防止するための統制が取られている。
上記いずれでもない。

補足 3

Cloud services are～潜在的なセキュリティホールを埋め込むリスクのある自前実装を避けクラウドのマネージドサービスを使いましょうという意図だと思いますが、良い文章が浮かばず直訳気味になってしまっています。

How are you monitoring security-related events in this workload?

ワークロードでセキュリティに関連するイベントをどのように監視しているか？

Tools like Azure Security Center are used to discover and remediate common risks within Azure tenants.

A central SecOps team monitors security related telemetry data for this workload.

The security team has read-only access into all cloud environment resources for this workload.

The security team has access to and monitor all subscriptions and tenants that are connected to the existing cloud environment, relative to this workload.

Identity related risk events related to potentially compromised identities are actively monitored.

Communication, investigation and hunting activities are aligned with the workload team.

Periodic & automated access reviews of the workload are conducted to ensure that only authorized people have access?

Cloud application security broker (CASB) is leveraged in this workload.

A designated point of contact was assigned for this workload to receive Azure incident notifications from Microsoft.

None of the above.

Azure テナント内の一般的なリスクを発見、修復するために Azure Security Center といったツールが使われている。
ワークロードでセキュリティに関するテレメトリデータを中央集権的な SecOps チームが監視している。
セキュリティチームはワークロードの全てのクラウド環境のリソースに対して、読み取り専用権限を持つ。
セキュリティチームはワークロードに関連し存在するクラウド環境につながる全てのサブスクリプションとテナントへアクセスし、監視する。
潜在的に危険にさらされているアイデンティティに関するリスクイベントが積極的に監視されている。
アクティビティに対するコミュニケーション、調査、刈り取りはワークロードチームに沿って行われている。
承認済みの人だけがアクセスしていることを確認するために、ワークロードの定期的かつ自動的なアクセス証跡のレビューが実施されている。
ワークロードで Cloud application security broker (CASB) が活用されている。
Microsoft からの Azure のインシデント通知を受け取るため、ワークロードで指定された連絡先が割り当てられた。
上記いずれでもない。

補足 4

Identity related～直訳だと Identity が重複するため、少し意訳しました。
Communication, investigation and hunting～刈り取りというよりは「対処」ぐらいの意味だと思われます。
Periodic & automated access～「証跡」という言葉は出てきませんが、前後のつながりを考えて付け足しました。

How is security validated and how do you handle incident response when breach happens?

どのようにセキュリティが検証され、違反が起こった際のインシデント対応をどのように制御しているか？

For containerized workloads, Azure Defender (Azure Security Center) or other third-party solution is used to scan for vulnerabilities.

Penetration testing is performed in-house or a third-party entity performs penetration testing of this workload to validate the current security defenses.

Simulated attacks on users of this workload, such as phishing campaigns, are carried out regularly.

Operational processes for incident response are defined and tested for this workload.

Playbooks are built to help incident responders quickly understand the workload and components, to mitigate an attack and do an investigation.

There's a security operations center (SOC) that leverages a modern security approach.

A security training program is developed and maintained to ensure security staff of this workload are well-informed and equipped with the appropriate skills.

None of the above.

コンテナ化されたワークロードで、脆弱性をスキャンするために Azure Defender (Azure Security Center) や 3rd Party のソリューションが使われている。
現在のセキュリティ防御を検証するため、社内もしくは第三者機関が侵入テストを実施している。
フィッシングキャンペーンのようなワークロードのユーザーを想定した攻撃が定期的に実行されている。
ワークロードでインシデント対応の運用プロセスが定義されテストされている。
インシデント対応者がワークロードやコンポーネントを素早く理解することを助け、攻撃や調査の手間を軽減するため Playbook が作られている。
モダンなセキュリティアプローチを活用する SOC がある。
ワークロードのセキュリティスタッフが十分な情報を与えられ適切なスキルが備わっていることを確認するために、セキュリティ訓練プログラムが開発・維持されている。
上記いずれでもない。

How is connectivity secured for this workload?

ワークロードの接続性はどのようにセキュアか？

Services used by this workload, which should not be accessible from public IP addresses, are protected with network restrictions / IP firewall rules.

Service Endpoints or Private Links are used for accessing Azure PaaS services.

Azure Firewall or any 3rd party next generation firewall is used for this workload to control outgoing traffic of Azure PaaS services (data exfiltration protection) where Private Link is not available.

Network security groups (NSG) are used to isolate and protect traffic within the workloads VNet.

NSG flow logs are configured to get insights about incoming and outgoing traffic of this workload.

Access to the workload backend infrastructure (APIs, databases, etc.) is restricted to only a minimal set of public IP addresses - only those who really need it.

Identified groups of resources are isolated from other parts of the organization to aid in detecting and containing adversary movement within the enterprise.

All public endpoints of this workload are protected/secured with appropriate solution (i.e. Azure Front Door, Azure Firewall...).

Publishing methods for this workload (e.g FTP, Web Deploy) are protected.

Code is published to this workload using CI/CD process instead of manually.

Workload virtual machines running on premises or in the cloud don't have direct internet connectivity for users that may perform interactive logins, or by applications running on virtual machines.

There's a capability and plans in place to mitigate DDoS attacks for this workload.

None of the above.

ワークロードでパブリック IP アドレスからアクセスすべきでないサービスユーザーは、ネットワーク制限や IP firewall rules で保護されている。
Azure PaaS へのアクセスのため、Service Endpoints や Private Links が使われている。
ワークロードで Private Link が利用できない Azure PaaS の漏洩保護として外部へのトラフィックを制御するため、Azure Firewall や 3rd party の次世代ファイアウォールが使われている。
ワークロードの VNet 内でトラフィックを孤立させ保護するために NSG が使われている。
ワークロードの内方向と外方向のトラフィックについて洞察を得るため、NSG flow logs が使われている。
API やデータベースといったワークロードのバックエンドインフラへのアクセスは、本当に必要な最小限のパブリック IP アドレス群に制限されている。
企業内の敵の動きを検出して封じ込めるのを支援するため、リソースの識別されたグループは組織の他の部分とは独立されている。
ワークロードの全てのパブリックエンドポイントは Azure Front Door や Azure Firewall といった適切なソリューションによってセキュアに保護されている。
FTP や Web Deploy といったワークロードの公開方法は保護されている。
コードは手動ではなく CI/CD のプロセスを使いワークロードへパブリッシュされる。
オンプレミスやクラウドで動いているワークロードの VM はユーザーとの対話的なログインや VM 上で動作しているアプリケーションと直接的なインターネット接続は無い。
ワークロードで DDoS 攻撃を緩和するための能力や計画がある。
上記いずれでもない。

How have you secured the network of your workload?

ワークロードのネットワークはどのようにセキュアか？

There's a designated group within the organization, which is responsible for centralized network management andxrw security of this workload.

There are controls in place to ensure that security extends past the network boundaries of the workload in order to effectively prevent, detect, and respond to threats.

Enhanced network visibility is enabled by integrating network logs into a Security information and event management (SIEM) solution or similar technology.

Cloud virtual networks are designed for growth based on an intentional subnet security strategy.

This workload has a security containment strategy that blends existing on-premises security controls and practices with native security controls available in Azure, and uses a zero-trust approach.

Legacy network security controls for data loss prevention were deprecated.

Traffic between subnets, Azure components and tiers of the workload is managed and protected.

None of the above.

組織内にワークロードのネットワーク管理とセキュリティに集中して対応する指定されたグループがある。
脅威を効果的に防止、検出、および対応するために、ワークロードのネットワーク境界を越えたセキュリティの拡張の確認が制御されている。
ネットワークログを SIEM のようなセキュリティ情報やイベント管理ソリューションもしくはそれに類似する技術で統合することで、ネットワークの可視化が有効になっている。
クラウドの仮想ネットワークは計画的なサブネットのセキュリティ戦略に基づいた増分を設計されている。
ワークロードがオンプレミスの既存のセキュリティ管理と Azure で利用可能なセキュリティ管理のプラクティスを混ぜ合わせ、ゼロトラストなアプローチを使用するセキュリティ封鎖戦略を持つ。
データ損失防止のためのレガシーなネットワークセキュリティ管理が非推奨である。
サブネット、Azure コンポーネント、ワークロードの階層間のトラフィックが管理・保護されている。
上記いずれでもない。

補足 5

～andxrw～意味がよくわからず typo のような気もするので、and で訳しました。
～a security containment strategy～直訳のセキュリティ封鎖戦略だとイマイチなのですが、良い訳が浮かばずそのままとしています。

How are you managing encryption for this workload?

ワークロードで暗号化をどのように管理するか？

The workload uses industry standard encryption algorithms instead of creating own.

The workload communicates over encrypted (TLS / HTTPS) network channels only.

TLS 1.2 or 1.3 is used by default across this workload.

Secure modern hashing algorithms (SHA-2 family) are used.

Data at rest is protected with encryption.

Data in transit is encrypted.

Virtual disk files for virtual machines which are associated with this workload are encrypted.

None of the above.

ワークロードでは業界標準の暗号化アルゴリズムを使用し、自身で作成はしない。
ワークロードでは TLS や HTTPS で暗号化されたネットワークチャネルでのみ通信される。
ワークロードの標準として TLS 1.2 もしくは 1.3 が使われる。
SHA-2 系統のセキュアでモダンなハッシュアルゴリズムが使われている。
保存データは暗号化で保護されている。
転送中のデータは暗号化されている。
ワークロードに関連する VM のディスクは暗号化されている。
上記いずれでもない。

Are keys, secrets and certificates managed in a secure way?

キーやシークレットや証明書はセキュアな方法で管理されているか？

There's a clear guidance or requirement on what type of keys (PMK - Platform Managed Keys vs. CMK - Customer Managed Keys) should be used for this workload.

Passwords and secrets are managed outside of application artifacts, using tools like Azure Key Vault.

Access model for keys and secrets is defined for this workload.

A clear responsibility / role concept for managing keys and secrets is defined for this workload.

Secret/key rotation procedures are in place.

Expiry dates of SSL/TLS certificates are monitored and there are renewal processes in place.

None of the above.

PMK と CMK のどちらにするかといった、ワークロードでどの種類のキーが使われるべきかという明確なガイダンスや要件がある。
パスワードやシークレットや Azure Key Vault のようなツールを使いアプリケーションアーティファクトの外部で管理されている。
ワークロードでキーやシークレットへのアクセスモデルが定義されている。
ワークロードでキーやシークレットを管理するための明確な責任や役割のコンセプトが定義されている。
シークレットやキーのローテーションの手順がある。
SSL/TLS 証明書の有効期限が監視され、更新プロセスが存在する。
上記いずれでもない。

What security controls do you have in place for access to Azure infrastructure?

Azure インフラへのアクセスのためにどのようなセキュリティ管理手段を持つか？

There are tools and processes in place to grant just-in-time access.

No user accounts have long-standing write access to production environments.

Appropriate emergency access accounts are configured for this workload in case of an emergency.

Lines of responsibility and designated responsible parties were clearly defined for specific functions in Azure.

The application team has a clear view on responsibilities and individual/group access levels for this workload.

Workload infrastructure is protected with role-based access control (RBAC).

Resource locks are leveraged to protect critical infrastructure of this workload.

Direct access to the infrastructure through Azure Portal, command-line Interface (CLI) or REST API is limited and CI/CD is preferred.

Permissions to Azure workloads are rarely based on individual resources and custom permissions are rarely used.

There are processes and tools being used to manage privileged activities. Long standing administrative access is avoided whenever possible.

There is a lifecycle management policy for critical accounts in this workload and privileged accounts are reviewed regularly.

None of the above.

必要な時だけアクセスを許可するツールやプロセスがある。
プロダクション環境へ長期間書き込み権限を持つユーザーアカウントは無い。
ワークロードの緊急時に適切なアクセスアカウントが構成されている。
Azure の特定機能のために責任範囲および指定された責任者が明確に定義されている。
ワークロードでアプリケーションチームは責任や個人・集団のアクセスレベルを明確に見える。
ワークロードのインフラは RBAC で保護されている。
ワークロードの重要なインフラを保護するため、リソースロックが活用されている。
Azure ポータルや CLI、REST API によるインフラへの直接アクセスは制限され、CI/CD が優先される。
Azure ワークロードへの権限は個々のリソースやカスタム権限とはめったに紐づかず、利用もされない。
特権を持った活動を管理するためのプロセスやツールがある。いつでも可能なときに長期間の管理者アクセスすることは避けられている。
ワークロードにおける重要なアカウントのためのライフサイクル管理ポリシーがあり、特権アカウントは定期的にレビューされている。
上記いずれでもない。

補足 6

Permissions to～rarely の訳が悩ましいですが、個別に権限設定せず RBAC のような組み込みロールを活用すべしというニュアンスが出せていればよいのかと思います。

How are you managing identity for this workload?

ワークロードの ID をどのように管理するか？

When communicating with Azure platform services managed identities are preferred over API keys and connection strings.

All APIs in this workload require clients to authenticate.

Modern authentication protocols (OAuth 2.0, OpenID) are used by this workload.

Azure Active Directory or other managed identity provider (Microsoft Account, Azure B2C etc.) is used for user authentication.

Authentication via identity services is prioritized for this workload vs. cryptographic keys.

Conditional access policies are implemented for users of this workload.

Password-less or multi-factor authentication (MFA) is enforced for users of this workload.

Current on-premises Active Directory is synchronized with Azure AD or other cloud identity system.

None of the above.

Azure プラットフォームにおけるマネージド ID の通信は API キーやコネクションストリングよりも優先される。
ワークロードの全ての API はクライアントに認証を要求する。
OAuth 2.0 や OpenID といったモダンな認証プロトコルがワークロードで使われている。
ユーザー認証のために Azure Active Directory やその他のマネージド IdP(Microsoft Account, Azure AD B2C など)が使われている。
ワークロードで ID サービス経由の認証が暗号化キーを使ったものよりも優先されている。
ワークロードのユーザーのために、条件付きアクセスポリシーが実装されている。
ワークロードのユーザーのために、パスワードレスや MFA が強制されている。
現在のオンプレミスの AD が Azure AD や他のクラウド ID システムと同期されている。
上記いずれでもない。

まとめ

今回は「セキュリティ」を取り上げました。5 回にわたって掲載してきた Azure Well-Architected Review の記事もこれで終了となります。今回まとめた内容を実システムに適用することで、クラウドの利点を活かしたシステムにブラッシュアップしていけるのではないかと感じました。今後継続して実践していきたいと思います。