お問い合わせ

Microsoft Azure Well-Architected Frameworkの概要

日本電気株式会社
サービスビジネス統括部
主任　長谷川　一郎

Azure Well-Architected Framework （以下、W-AF）は Microsoft Azure 上のワークロードの品質を高めるベストプラクティス集であり、コストの最適化、オペレーショナルエクセレンス、パフォーマンス効率、信頼性、セキュリティの 5つの柱で構成されている。また、5つの柱に加えて一般的な設計原則があり、アーキテクチャー進化を実現、データを使用した意思決定、教育と有効化、自動化をアーキテクチャー全体で考慮する。更に、クラウドに移行すると共同責任のモデルが導入される。クラウドプロバイダーが提供しているレイヤー（サービス）のデータセンターの稼働維持、ネットワーク接続などに関してユーザーは考えなくてよいため、アプリケーションの実装などに専念できるようになる。

W-AF を適用する際にはいくつか注意する点がある。あくまでも参考として現状を認識し、今の状態を把握できればよいため W-AF を全て受け入れる必要はないという点である。そして、抽出された課題はその重要性、優先順位、必要性を現場でのビジネス要件を踏まえて自身（チーム）で決めてよい。見つかった事項は他の項目とトレードオフの可能性があることは注意しなければならない（性能とコスト、など）。

W-AF レビューでチェックリストと照らし合わせて現状を確認していく。全てがチェックリストの通りになっている必要はなく、リスクを認識し、その後の改善点を考えることが重要になる。W-AF レビューでは質問事項が多岐にわたるため関係者（各分野のエキスパート、運用担当者、プロジェクトマネージャーなど）を交えて W-AF レビューを行い、W-AF レビューの回答の中では「なんとなくそうなった」もしくは「わかっているが理由があってあえてそうしている」のどちらかを明確にする。さらには Microsoft Cloud Adoption Framework（以下、CAF）と同様に 1回だけではなく複数回実施することが重要である。設計段階開始、途中、完了、リリース前など複数回行う、対象となるアーキテクチャーにより期間は異なるが定期的に行うことで現状確認と改善点を見つけていくことが重要である。

また、ワークロードの改善を運用プロセスに組み込むことが重要。これは「Well-Architected 推奨プロセス」として Microsoft 社から紹介されている。特にワークロードの評価を行う部分には W-AF レビューだけでなく様々なツールが用意されている。

コストの最適化の目的は組織が投じる費用が最大の効果で使用されるようにすること。具体的には、資産を保有して減価償却をするモデルからクラウドを利用することで資産を持たない従量課金モデルに移行することで、適切なリソースと適切なサイズを利用することが可能になる。結果、クラウド利用することによりコストの最適化が行われ、ビジネスの成果に直接影響を与える。

オペレーショナルエクセレンスの目的はビジネスの変化に迅速に対応すること。そのために運用上の機能強化を進めていくことになる。代表的な例としては DevOps と継続的インテグレーション、自動化（Infrastructure as Code によるデプロイ）、アプリケーションのユーザーエクスペリエンス向上とテストによる品質改善などがあげられる

パフォーマンス効率の目的はアプリケーションが利用するリソースをパフォーマンス要件と合わせること。そのためにピークパフォーマンスをどのように確保するかという検討が必要である。実際にやることの例として、リソースのスケーリング、ボトルネックの特定と最適化、アプリケーション コードの最適化などがあげられる。

信頼性の目的はインシデントの影響がない状態でシステムが要求を処理継続すること。そのために、インシデントの影響を迅速かつ自動的に除去する仕組みが必要である。たとえば、各コンポーネントに高可用性を統合して局所的な障害をアプリケーションで確実に処理する、単一障害点を排除した設計でインフラストラクチャーのメンテナンス影響を最小化する、といった方法が考えられる。

セキュリティの目的は組織が使用、保存、送信するデータを保護すること。ここではいくつかの観点を提示するだけに留める。ひとつは、法的要件および規制上の要件であり、所在地や業界によってもデータの取り扱いのルールが異なる。また、多層防御という考え方もある。セキュリティ態勢を強化するための階層型アプローチである。

最後に、W-AF の学習や情報収集に活用できる Microsoft Learn のコンテンツを長谷川氏から紹介した。

Microsoft Azure Well-Architected Framework によるシステムのパフォーマンス改善

Performance Excellence とはワークロードの負荷に応じてコスト最適化を考え、パフォーマンス効率を考えてリソースを使用することである。Performance Excellence が何かを理解した上で考えるべきことは 3つある。

1つ目はビジネス要件に沿った要件定義を行い、SLA に従った性能目標をだすこと（ただし、性能を出すためにコストをかけすぎると赤字にならないように注意する）。
2つ目は PaaS、SaaS を活用してコストの最適化を行うこと。代表的な例としては、モノリスとマイクロサービスどちらで開発するか、応答時間短縮を行う、RDBMS と NoSQL のどちらを使用するか、応答時間短縮のためのインフラ設計、などがあげられる。
3つ目は常に計測をすることである。計測をしていないと異常が起きた時になにが起きているかわからなくなってしまう可能性がある。関連してリリース時にどのようなテストをするか考えておく必要がある。

設定変更を考える場合にはまずは計測を行い、現在の状態が異常か正常かメトリクスを見て判断する必要がある。この時点で注意すべきなのはそもそも異常ではない状態を知らなくてはならないということである。Microsoft Azure では Azure Monitor を使用することで複数のサービスのデータを統合的に取得できる。負荷テストでは Azure Load Testing、インフラ異常系テストでは Azure Chaos Studio を使うことでそれぞれのテストが比較的容易にできる。

オンプレミス時代は Zabbix、Hinemos、Pandora など様々な計測ツールがあり、クラウド上でも IaaS 上では使用できるが PaaS 上では使用できない。PaaS を計測する場合には対応している PaaS を選ぶ（Microsoft Azure では Azure Monitor）。クラウド上ではオンプレミスサービスと比較してできないことがあり、代表的なものとしては即時通報である。クラウドではどうしても若干のタイムラグが生じてしまうためである。加えて Microsoft Azure そのものの通知には Service Health を使用することで確認できる。また、Application Insightsという Microsoft Azure の各種サービスのモニタリングサービスがあり、本番環境では最初から有効にしておく。Web アプリケーションの場合は複数のサービスと連携することが多いことが想定されるが、Application Map でそれぞれの依存関係をグラフで視覚的に確認できる。

計測により性能不足が分かった場合はまずインフラ構成の変更前にできることを考える（ただし、Web Apps は Diagnose and solve problem に性能、セキュリティリスク、ベストプラクティスが記載されており、ほぼこちらで解決できる）。まずできることはスケールアウトとスケールアップを対象システムに応じて行うことである。

正常時の状態がわからないと異常時にどこが悪いかを判断するために、リリース前の負荷テストを行わないと正常時の状態がわからず、何が異常かもわからなくなるため、重要である。Microsoft Azure では負荷テストに申請は原則不要であるが、テスト内容（Azure AD（Entra ID）などを使用する場合）によっては別テナントが必要になる。この負荷テストを行った後に特定のテストを基準として設定する。これは基準を作成することで後のテストの性能が正常かどうかの比較がしやすくなるためである。このような負荷テストは夜中や休日に CI と一緒に定期的に行うのがよい。突然の負荷上昇、突然攻撃対象になること、PaaS のエラーを防ぐためにサービスリリース後も継続的な計測が必須である。

アプリケーションアーキテクチャーではモノリス、マイクロサービス両方で考慮するべきことがある。マイクロサービスでは特定の Pod が専有している状態や Pod 間通信がノードをまたがってしまうと性能が落ちてしまうことに注意する必要がある。モノリスでも、クライアント→ネットワーク → Web → DB と分割されるので調査が必要な箇所は多くなる。自動ではなくきちんと見定めて適切なスケーリングも必要である

アプリケーションを積極的に移行する必要がある。.NET は Microsoft 社自身が使用しており、インフラの運用コストが下げられるので大きな投資がされている。Azure AD Gateway（Edge サーバー）は移行するたびに 30-50％改善、コア数が 4万 → 2万と大きな削減事例がブログで出ており、.NET の世代が古いものは移行してみると効果が期待できる。

最後に、パフォーマンスは一度計測して終わりではなく、日々計測を行い、何が異常なのかをわかるように基準を設定することが重要である。ただしいきなりすべてを行うのは難しいので徐々にでも行うことが大事、と亀川氏は締めくくった。

Microsoft Azure Well-Architected Framework セキュリティの柱で Well-Secured

冒頭で、はじめに守りたいモノを定義する、セキュリティは投資である、というセキュリティにおける重要な考え方について釜山は語った。

概要と原則

Microsoft Azure Well-Architected Framework（以下、W-AF）とはワークロードの品質向上に使用できる一連の基本原則で、コスト最適化、オペレーショナルエクセレンス、パフォーマンス効率、信頼性、セキュリティの 5つの柱で構成されている。それぞれの柱は相関関係にあるが、特にセキュリティの柱は相関性が色濃く出て、網羅的に課題を抽出でき、それをワークフローの改善につなげられる。

セキュリティの重要な要素の概要

最初に情報セキュリティの CIA（Confidentiality：機密性、Integrity：完全性、Availability：可用性）が原則として存在しており、可用性はセキュリティの要素であることが忘れがちであると指摘した。

次に専門化は、データセンターの物理的なセキュリティ、ファームウェアのパッチ適用、ハイパーバイザーの構成があげられ、何れもクラウド事業者側が担っているタスクである。

最後に、主要な戦略ではシステムの優先順位、セキュリティ上のリスク対応の 2つがポイントとしてあげられる。特にセキュリティ上のリスク対応の中には、最新の境界の確立、インフラストラクチャーセキュリティの最新化、各クラウドプロバイダーを「信ぜよ、されど確認せよ」の 3つが含まれている。

その他の要素としては ID 管理、インフラストラクチャー保護、アプリケーションセキュリティ、データの支配権と暗号化、セキュリティリソースがあげられる。

ID 管理では認証と承認（認可）を保護する。オンプレミス、クラウド関係なく ID が乗っ取られると多くのセキュリティ侵害につながる可能性があるため、ID 管理の重要性は高い。

インフラストラクチャー保護では、Azure RBAC ロールによる正しいアクセス許可の付与と、インフラストラクチャーにおける全ての変更における監査があげられる。監査にはアクティビティログの利用が基本であり、その他、オブザーバビリティ（可観測性）製品の活用も有効な手段である。

アプリケーションのセキュリティでは、通信においてサポートされている最新バージョンで転送データを暗号化する。暗号方式が古いと既知の脆弱性を悪用するツールなどで容易に通信の内容が傍受される可能性があるためである。また、CSRF、XSS、SQL インジェクションといった頻出しているアプリケーションに対する攻撃からの防御も重要になる。

データの支配権と暗号化では、まずはデータ所在地を把握する。各国でデータに関する法律が異なっている状況や、国外での紛争リスクを回避等の対応で、データの保持を自国内のデータセンターに閉じるケースがある。一方で、国内での紛争や大規模災害等のケースでは、データが消失してしまう可能性があるため、このケースにおいてはデータを国外で保持する設計が合理的と言える。 加えて、責任共有モデルをセキュリティの観点から解説する。よく責任分解と言われることがあるが、必ずしも明確に責任分解出来るとは限らない点に注意する。

情報セキュリティとサイバーセキュリティの違い

Microsoft Azure Well-Architected Framework（以下、W-AF）とはワークロードの品質向上に使用できる一連の基本原則で、コスト最適化、オペレーショナルエクセレンス、パフォーマンス効率、信頼性、セキュリティの 5つの柱で構成されている。それぞれの柱は相関関係にあるが、特にセキュリティの柱は相関性が色濃く出て、網羅的に課題を抽出でき、それをワークフローの改善につなげられる。

セキュリティの柱で扱う領域

セキュリティ設計原則、ガバナンス・リスク及びコンプライアンス、規制コンプライアンス、管理、アプリケーションとサービス、ID管理とアクセス管理、情報の保護とストレージ、ネットワークセキュリティと封じ込め、セキュリティ運用がセキュリティの柱で扱われる領域である。

セキュリティ設計原則

・リソースとその強化方法を計画する セキュリティ後になればなるほどセキュリティに係る費用や工数がかさむため、セキュリティ・バイ・デザインに基づき計画・設計時にセキュリティを講じておくのが重要である。クラウドにおいて、サービス毎に責任範囲が異なる。クラウド利用者における OS へのパッチ適応のタスクは、IaaS における仮想マシンでは対応が必要だが、PaaS では不要だ。このようにサービスよって異なるユーザーの責任範囲を把握することが重要である。

・最小限の特権を自動化して使用する 緻密な設計により特権を最小限にとどめ、手動による誤操作を防止するために自動化するのも重要である。ただし、自動化が進みすぎるとブラックボックス化して保守性（メンテナビリティ）が低下してしまうケースがあるため、保守性を考慮した設計が必要がある。

・データを分類して暗号化する リスクに応じてデータを分類すること、これはまさに冒頭の「はじめに守りたいモノを定義する」である。

・システムのセキュリティを監視し、インシデント対応を計画する インシデント発生時において、インシデントレスポンスの訓練やインシデント対応フローの整備など、事前準備の成果が顕著に表れる。事前準備にない事項を本番で初めて行うことは困難である。インシデント対応フローの整備は、正常系と異常系の整理が重要である。昨今のクラウド環境は大きくってきていることから、SIEM を利用するなどで合理的で円滑なセキュリティ運用が求められている。

・エンドポイントを識別して保護する ホストであればアンチウイルスやホスト型IDS/IPS、ネットワークであればファイアウォールやネットワーク型 IDS/IPS、Webアプリケーションであれば Web アプリケーションファイアウォールなどで保護する。

・コードレベルの脆弱性から保護する しておらず、脆弱性にはソフトウェアのバグだけではなく、設定ミスも含まれるため、必ずしもセキュリティパッチが作成されるとは限らない。運用ライフサイクルに依存関係を含めてコードレベルの修正を組み込む。

・潜在的な脅威に対するモデル化とテスト 脅威に関して事前に様々な情報を収集した上で適切な対応（既知の脅威を特定して軽減する手法の確立、新入テストの実施、など）を行う。

セキュリティの柱で扱う主な領域

ガバナンス、リスク、およびコンプライアンスではセキュリティの優先順位、ライフサイクルを通じたセキュリティ標準の管理、が重要となる。またランディングゾーンの作成によりインフラストラクチャーの管理ができてデプロイのたびに繰り返せること、Azure Policy によりサービスとその構成と削除を適用することがチェックすべき項目である。

規制に対するコンプライアンスでは、全ての規制及びガバナンスの要件が把握されていて十分に理解されていること、外部及び内部のワークロードセキュリティ監査を定期的に実施する、ワークロード操作の一環としてコンプライアンスチェックを実施する、Microsoft Trust Center を利用する、の 4つが重要なポイントである。また、制限が厳しい環境ではコンプライアンス対応にコストと時間がかかるが、この部分を以下に効率的に行うかがポイントになる。特に、Microsoft Trust Center には監査レポートが存在するのでここから監査レポートを確認する。

管理者アカウントのセキュリティは 13 の項目の全てが重要である。管理者アカウントが乗っ取られると高い権限で悪用されてしまうため、管理者アカウントの数を最小限にし、場合によっては管理者アカウントを無効にする。その他、管理者用のアカウントを分離する、Just in Time 特権を利用する、非常時のアカウントを用意する、パスワードレス認証や多要素認証の実装、条件付きアクセスの適用等、管理者アカウントの保護に力を入れるべきである。 Microsoft Azure の ID 及びアクセス管理に関する考慮事項（IAM）において、管理者アカウントのセキュリティと同様に注意する。

セキュリティ運用

NIST Cybersecurity Framework における Detect、Respond、Recover の 3つを取り上げてタスクを整理し、いかにセキュリティ運用を合理化して迅速に対応するかが重要である。

そして最後に「いつもサイバーセキュリティを」という言葉で釜山氏は締めくくった。

お問い合わせ