• Microsoft Azure の IaaS (Infrastructure as a Service)

• わずか数分で Azure データセンターで仮想サーバーが起動

• 使った分だけ、分単位の従量課金

• Windows も Linux も

• 仮想化レイヤーより下はクラウドベンダーが責任をもって管理

• 仮想マシンの OS より上はユーザーが責任をもって管理

• 仮想化レイヤーより下についてはクラウドベンダーが責任をもって管理する➢ クラウドベンダーがどのような安心・安全を

提供してくるかは、きちんと確認すること

• 仮想マシンの OS より上の安心・安全はユーザーが責任をもって管理する➢ OS

➢ ミドルウェア・ランタイム

➢ データ

➢ アプリケーション

高可用性 (HA)

バックアップ

災害対策 (DR)

HWやSWのトラブルが発生しても、

業務を継続できるようにする

データが消失または破損したとき、

それを復旧できるようにする

大規模災害でデータセンターが

稼働できなくなったとき、

早期に業務を再開できるようにする

• Azure の仮想化ホスト基盤は、すべて冗長化されている。

• Azure 仮想マシンが稼働する仮想化ホストで障害が発生したとき、そのAzure 仮想マシンは自動的に別の仮想化ホストで再起動する。

• 常に同時に３つのディスクへデータが書き込まれる。

• 最大で同時に２つのディスクが壊れても、データ損失なく稼働する。

VHD ファイル

• ジオ冗長ストレージ(GRS)を使うと、データが自動的に別データセンターにも非同期で複製される。

• 複製元での３重化＋複製先での３重化＝合計６重化。

> 500 miles

東日本 西日本

Blob ストレージBlob ストレージ

• GRS はストレージをペアリージョンに非同期で複製する。

• GRS の複製時にはOS 内での整合性は考慮されない。

• 複数のディスクがある場合、各ディスクが異なるタイミングで複製されうる。➢ 記憶域スペースや LVM を使っている場合、不整合が生じうる。

• GRS のフェールオーバーはマイクロソフトの判断により実行される。➢ 利用者任意のタイミングでのフェールオーバーはできない。

災害時の業務継続が目的であれば、別の手段も検討する。

• 所有しているリソースに影響を及ぼしうる Azure 上の問題について、情報や解決策を提供する。➢ 自分の所有しているリソースに影響のない問題は表示されない。

➢ Azure ポータル上のアイコンから参照できる。

• Azure 仮想マシンが１台停止しても業務を停止させたくないときは、複数台の仮想マシンで冗長化構成を組む。

• どう冗長化構成を実装するかは、サーバーの種類により異なる。

• Azure 仮想マシンでは原則としてディスク共有型のクラスタを構成できない。➢ とくにファイルサーバーやDBサーバーにおいて要注意

• RDMBS の機能や3rd パーティのソリューションを利用した、ディスクを共有しない冗長化構成を考える。

〇 Azureではこちらを利用する× Azureでは原則として利用できない

• Windows Server 2016 の機能である S2D (Storage Space Direct : 記憶域スペースダイレクト)を使い、Azure 仮想マシンでSQL Server AlwaysOn フェールオーバークラスターを構成できる。

• ただし S2D を使えばあらゆるワークロードでディスク共有型クラスタが構成できるわけではない。利用しているワークロードが共有ディスクとして S2D の構成をサポートしているか確認が必要。

• Azure 仮想マシンを複数台構成にするときは、可用性セットを定義する。

• これにより、１つのラックの障害で２台の仮想マシンが同時に停止することを回避できる。

• 可用性セット自体にクラスタリング・負荷分散・データ複製などの機能があるわけではないので注意すること。

障害ドメイン 障害ドメイン障害ドメイン

ラック

FC

・・・

・・・

ルータ

ラック

FC

・・・

・・・

ルータ

ラック

FC

・・・

・・・

ルータ

可用性セット

“AS1”

• 障害ドメイン (FD)➢ 同時に物理障害が起こりう

る単位 ≒ ラック

• 更新ドメイン (UD)➢ 同時にメンテナンスを行う

単位

• 2017年2月にGAした仮想マシンの新しいディスク形式。

• いろいろなメリットがあるが、➢ ストレージアカウントの作成・管理が不要に

➢ スナップショット、仮想マシンイメージの容易な作成

➢ Blobとしてのエンドポイントが無い

• 実は Managed Disk では可用性も向上している！➢ 可用性セットに含まれる仮想マシンのManaged Diskは

自動的に異なる障害ドメインに配置される。

➢ 可用性セットを構成する場合は、Managed Disk を使うことを強く推奨！

• こういうことは、いつ発生してもおかしくない！

設定を変更したところ OS が起動しなくなった

誤って重要なファイルを消してしまった

アプリのバグによりデータベースのデータが破損してしまった

「定期的に」

• Azure 仮想マシンのディスクをまるごとバックアップ

• 稼働中にオンラインでバックアップ取得可能

• Windows にも Linux にも対応

• Azure ポータルの仮想マシン設定画面から、

簡単に構成・操作できる

• 主要なAzure Backupの利用形態として以下の３種類がある。

1. Azure 仮想マシンのバックアップ

2. オンプレミスの仮想マシンやDBのバックアップ

3. ファイルやフォルダのバックアップ

今日お話しするのはこれ

Azure Backup

• Windows では VSS を利用したアプリケーション整合性バックアップが取得できる。➢ SQL Server などの VSS に対応したアプリケーションであれば、アプリ

ケーションのレベルで静止点を取って、バックアップを行う。

• Linux でもユーザーが独自にバックアップ事前・事後スクリプトを設定することにより、アプリケーション整合性バックアップを取得することができる。(プレビュー)➢ VM 内にスクリプトを配置しておくと、バックアップ事前・事後にそれが自

動的に実行される。

➢ スクリプトが無い、もしくは失敗した場合でも、ファイルシステム整合性バックアップが実行される。

1. 仮想マシン全体のリストア➢ Managed Disk の仮想マシンであれば、そのままManaged Diskの仮想マ

シンとしてリストアされる。

2. ディスクのストレージアカウントへの復元➢ 復元したディスクの利用方法にもいくつかのパターンがある

1. ARMテンプレートを使って復元したディスクから新規仮想マシンを作成

2. 復元したディスクを既存の仮想マシンに接続

3. PowerShellを使って復元したディスクから新規仮想マシンを作成

• Azure Backup は現時点で以下をサポートしない。

1TB よりも大きなディスク➢ つまり 4TBディスクは未サポート

16本よりも多くのディスクを接続した仮想マシン

存在している仮想マシンの上書きリストア➢ まず仮想マシンを削除してからリストアする必要がある

• いずれも将来的にはサポートされる予定。

• 仮想マシン全体ではなく、特定のファイルやフォルダだけをリストアする機能もある。(プレビュー機能)

• 過去時点のディスクがiSCSI ディスクとして仮想マシンに接続され、そこから必要なファイル・フォルダを取り出すことができる。

Azure Backup

iSCSI ディスクとして接続

• Azure Backup では稼働中のオンラインバックアップが可能だが、バックアップ取得は業務ピーク時を外すこと。➢ バックアップ取得時にはストレージアカウントに対して大量のアクセスが発

生し、業務に影響を及ぼす可能性がある。

• 多数の仮想マシン/ディスクを1つのストレージアカウントに詰め込みすぎないようにする。

• 特にバックアップ・リストアの性能が重要な仮想マシンについては、Premium Storage の利用を検討する。

• ジオ冗長ストレージ(GRS)により、バックアップデータを別リージョンに複製することもできる。

Azure Backup

• GRS 同様、 Azure Backup サービス自体のフェールオーバーもマイクロソフトの判断で実施される。

災害時の早期業務再開のためには、ASR が適切な選択肢。

• 堅牢な Azure データセンターであっても、大規模災害により稼働停止する可能性はゼロとは言えない。

• 災害の規模や状況によって、稼働再開までに時間がかかる可能性も。

必要最低限の業務だけでも早めに再開したい

他地域・海外の利用者にサービス提供を継続したい

• Azure 仮想マシンのデータを、常に別のAzure データセンターに同期する。

• 大規模災害で Azure データセンターが被災したときに、複製されたデータをもとに別の Azure データセンターで仮想マシンを起動し、業務を再開できる。

• 料金は¥2,550＋ストレージ料金のみ。DR 用仮想マシンの料金が発生するのは、フェールオーバー先で仮想マシンを起動したときのみ。

• Azure Site Recovery には以下の２種類がある。

1. オンプレミスから Azure への DR

2. ２つの Azure データセンター間での DR (プレビュー)

今日お話しするのはこれ

• VM内で動作するエージェントが、同一リージョンのキャッシュストレージに変更データを書き込む。

• キャッシュストレージから複製先リージョンにデータが複製される。

• フェールオバー後に仮想マシンが正しく起動するか、事前にテストしておくことが重要。

• 複製元仮想マシンを稼働させたまま、テストを実行できる。

• 一般的にフェールオーバー手順は複雑になりがち。➢ 手順書を見ながら実行しても、ミスする可

能性がある。

• 複数の仮想マシンからなる複雑なシステムのフェールオーバー処理を、復旧計画として定義できる。➢ 仮想マシン起動の順序や、Azure

Automation Runbook の実行などを定義しておく。

➢ フェールオーバーの際は、この復旧計画を実行すればよい。

• ASR はディスクイメージ全体を非同期で複製する。➢ Active Directoryドメインコントローラーでは、データの不整合が発生する

可能性がある。

• 原則として、Active Directoryドメインコントローラーには ASR を利用しない。

Active Directoryによるデータ複製

Azure Site Recovery

• 1TB を超えるディスクはサポートされない。➢ これは Azure リージョン間での ASRについての制約。オンプレミスから

Azure への ASR では、4TB ディスクがサポートされた。

• Managed Disk はサポートされない。

• 以下の構成については、フェールオーバー時に復旧計画から自動化スクリプトを実行して構成する必要がある。➢ ロードバランサー(内部・外部ともに) / Traffic Manager

➢ Network Security Group (NSG) など

• ASR ではフェールオーバー時にIP アドレス体系を保持することも変更することも、どちらも可能。➢ IPアドレス体系を保持する場合、オンプレミスを含めたルーティングやIPア

ドレスのバッティングの回避などについての考慮が必要。

➢ IPアドレス体系を変更する場合、アプリの正常動作について確認が必要。

10.3.0.0/1610.2.0.0/16

IPアドレス体系重複のため同時接続はNG

IPアドレスが変わっても正常に動作するか？

IPアドレス体系を保持しないIPアドレス体系を保持する

• 社内 WAN からAzure 東日本リージョンへ ExpressRoute で接続していた。

• 災害が発生、ASR で西日本リージョンへフェールオーバーした。

• 社内 WAN から西日本リージョンへどう接続する？

1. あらかじめ西日本リージョンへも ExpressRoute を引いておく。➢ 災害対策用であれば従量課金がおすすめ。

2. Site-to-Site VPN 接続する。➢ 例えば、関西の業務拠点にVPN装置を配置しておき、フェールオーバー時に接続する。

3. 例外的にインターネット経由での接続を許可する。➢ 大規模災害時には社外からのアクセスに対するニーズが高まると予想される。

• 仮想化レイヤーよりも下のセキュリティは、クラウドベンダーが責任を持つ

• 仮想マシンの OS より上のセキュリティはユーザーが責任をもって管理する➢ OS (設定、更新プログラム、パスワード)

➢ ミドルウェア・ランタイム (設定、更新プログラム)

➢ データ (暗号化、アクセス権)

➢ アプリケーション (脆弱性)

やるべきことはオンプレミスと大きくは変わらない

• 仮想マシンのディスク(ストレージ)暗号化には２つの種類がある。➢ 仕組みや目的が異なる。併用も可能。

1. Azure Disk Encryption ➢ BitLocker(Windows) および DM-Crypt(Linux)

➢ 暗号化キーは Azure Key Vault で管理

➢ ポータルからVHDをダウンロードしても暗号化状態が保たれる

2. Storage Service Encryption➢ Azure ストレージの機能で、データ保存時に暗号化、データ取得時に複合化

➢ ポータルからVHDをダウンロードするとその時点で暗号化が解除される

➢ Azure データセンターからの物理的な盗難などのケースに役立つ

• インターネットから RDP(3389)/ssh(22) ポートにアクセス可能な状態にすることはリスクが高い。考えられる対策は以下。

1. Site-to-Site VPN/ExpressRoute 経由で、オンプレミスからしかアクセスできないようにする。

2. NSG(Network Security Group)でアクセス可能なIPアドレスを指定

3. 通常時は RDP(3389)/ssh(22) へのアクセスをブロックしておき、必要な時だけ NSG の設定変更でアクセスを許可する。➢ Azure Activity Log による NSG 設定変更時のアラート発行も設定

4. RD ゲートウェイを構築し証明書や多要素認証を組み合わせる。

クラウド環境

Operations Management Suite

オンプレミス DC

• セキュリティをはじめとするITインフラ品質強化

ログやシステム情報 マイクロソフトの知見および機械学習

• WindowsだけでなくLinux AzureだけでなくVMwareやAWS、物理サーバー

Log Analytics

改ざん不可能なクラウド

機械学習を活用した不正なふるまい検知

セキュリティ攻撃が疑われるふるまいを検知

人工知能を活用

不正なIPアドレスとの通信の検知

不正なIPアドレスとの通信を検知

アップデート適用状況を可視化

セキュリティベースラインの評価

マイクロソフトのベストプラクティス改善すべき設定項目

OMS ワークスペースの作成

Azure 仮想マシンの OMS への接続

脆弱性を指摘し、強化策を提示

侵入を検知

• パブリッククラウドのセキュリティでもっとも注意すべきことは、管理ポータルへの不正アクセス。

• Azure サブスクリプション管理者のアカウントに対しては、必ずMFA (多要素認証) 設定しておくこと。➢ IDとパスワードに加えて、SMS/電話/アプリなどでの認証を必須とする。

➢ 組織アカウントでも Microsoft アカウントでも設定できる。

• 仮想マシン作成時には、以下のアプローチを検討してください。

停められないシステムは複数台で冗長化構成にし、可用性セットを定義する。Managed Disk も活用する。

データやOSの破損・消失に備え、Azure Backup を必ず設定する。

特に重要な、大規模災害時にもすぐに利用再開したいシステムについては、Azure Site Recovery でDRを構成する。

セキュリティ強化のため、OMS (Log Analytics) および AzureSecurity Center を活用する。➢ 具体的なセキュリティ強化策についてクラウドがガイドしてくれる。