Azure/KUSANAGIでWEBアプリサーバーとDBサーバーを別けてワードプレスを構築
Microsoft Azureのリソースグループ内にVN(仮想ネットワーク）を作り、その中にWEBアプリサーバー（フロントエンド）とDBサーバー（バックエンド）をサブネットで別けてKUSANAGI仮想マシン2台で構築、そしてWordPressを動かします。仮想ネットワーク/ネットワークセキュリティグループを学習する必要があります。AzureにおけるファイヤーウォールはNSG（ネットワークセキュリティグループ）となり、『NIC【ネットワークインターフェイス（カード）】』、『サブネット』、『クラシックの仮想マシン』の3ヵ所に対してNSGを張ることが出来るという点がポイントです。NSGにおける受信セキュリティ規則/送信セキュリティ規則の設定も一緒に学習しておくことを強く推奨します。
PowerShell と Azure Resource Manager は使わず、AzureはGUI、個別の仮想マシンにはSSH接続にて対応します。WordPress以外のCMSやphpフレームワーク開発などにも応用できます。カートシステム系CMSの場合は、PCI DSS対応の為にDBサーバーの隔離だけではなく、DB暗号化、WEBサーバーとDBサーバーの通信の暗号化、暗号鍵分散管理など、データが移動する全過程にわたった暗号化が求められます。
PCI DSSの適用基準は、Eコマースの年間の取引件数（規模）や時代の流れによって異なりますので、開発前の計画段階から必須要件を調べて盛り込む必要があります。DBサーバーをフロントエンドのWEBサーバーから隔離して運用するという条項は、PCI DSSの要件v3.2で1.3.6を見ると「 DMZ やその他の信頼できないネットワークから隔離されている内部ネットワークゾーンで、カード会員データを保存するコンポーネント（データベース）が実装されている。 」となっており、マイルストーンは2です（1が最優先）。
本来は、apacheなどのWEBサーバー、ワードプレスなどのアプリサーバー、DBサーバーの3つのサーバーを構築し、WEBサーバーだけをネットワークで隔離してDMZに置きますが、今回は、WEBサーバーとアプリサーバーをWEB(アプリ)サーバーとしてまとめて、DBサーバーとあわせて2サーバーの構成でサブネットで分離して作ります。厳格にDMZとアプリサーバーとDBサーバーをネットワークで別ける構成については、改めて設計が必要です。
以下、データが移動する全過程にわたった暗号化についての説明は含んでおりません（改めて少しずつ記事を書きたいと思います）。
外枠のMicrosoftAzureの青線はDDOS防御してくれています
Microsoft クラウド サービスとネットワーク セキュリティを参照していただくとわかりますが、インターネットから受信する場合は、Azure DDoS が Azure に対する大規模な攻撃から保護します。カッコイイ！ただし、ネットワークレイヤーです。SYN Cookie、コネクション制限、レート制限を行っています。
原発、医療、製鉄など、インターネット切断が生命に直結するケースを除き、あらゆるシステムはクラウドに移した方がファイヤーウォールなどの多層化防御も充実させられて、物理サーバー費用も削減出来ます。グローバルに冗長化できる点も企業の大切なデータを守る意味では、オンプレミスに比べてクラウドがはるかに有利です。まだまだ、物理オンプレミスからクラウドへのシステム環境移行トレンドは続いています。
AzureでKUSANGIの仮想マシン2台を配置するためのネットワーク環境を構築
仮想マシンの構築前に上記の様にリソースグループ/仮想ネットワーク/サブネットを構築します。Azureポータルにログイン後、「リソースグループ」⇒「追加」と進み、リソースグループ名に「RSG01」、該当のサブスクリプションを選択、リソースグループの場所で「西日本」などを選び、「作成」をクリック、リソースグループが出来ます。
次にAzureポータルのトップページで「新規」⇒「ネットワーキング」⇒「仮想ネットワーク」⇒「作成」と進みます。Azure旧ポータルによるレガシーなクラシック仮想マシンを使わない限り、デプロイモデルの選択はResource Managerを選んでください。今後、Power ShellやAzure CLIなどを使う場合にResource Managerは重要になっていきます。仮想ネットワークの作成画面でNameに「VNet01」、アドレス空間に「192.168.0.0/16」、サブネット名「SBnet01」（フロントエンドサブネット）、サブネットアドレス範囲「192.168.1.0/24」、該当のサブスクリプションを選択、Resource Groupで先ほど作った「RSG01」を選択、場所についても「RSG01」に合わせて「西日本」を選択、最後に作成をクリック。
※仮想ネットワークを1つ作ると、必ずサブネットも1つ作られる、という規則になっています。
さらに、サブネットを追加します。「ダッシュボード」⇒「リソースグループ」⇒「RSG01」⇒「VNet01」⇒「サブネット」⇒「+サブネット」と進みます。ゲートウェイサブネットを選ばない様に注意！名前に「SBnet02」（バックエンドサブネット）、アドレス範囲（CIDRブロック）に「192.168.2.0/24」と入力、「ネットワークセキュリティグループ」と「ルートテーブル」は無しで「OK」をクリックします。これで上記のネットワーク構成が出来上がりました。
※ゲートウェイサブネットは、オンプレミス環境とVPN構築を行う場合など、異なる（仮想）ネットワーク間で通信を行う際に使います。同じネットワーク内であれば、サブネット間の通信はプライベートIPアドレス（内部IPアドレス）を使って自由に出来ます。
WEBサーバー用のKUSANAGI仮想マシンを立ち上げる
KUSANAGI for Microsoft Azureを使ってWEBサーバー用の仮想マシンを立ち上げます。Azureの「ダッシュボード」⇒「Virtual Machines」⇒「追加」⇒「kusanagi」で検索⇒「KUSANAGI for Microsoft Azure」が検索結果で2個出てきますが、上にあるやつを選択⇒「作成」と進み、WEBサーバー用のKUSANAGI仮想マシンの名前をkusaVM01とします。以降、KUSANAGI for Microsoft Azureのページを参照しながら、仮想マシンのデプロイまでを行ってください。Resource Group（リソースグループ）では「RSG01」、ネットワークで「VNet01」、サブネットで「SBnet01」として間違わない様に選択してください。ネットワークセキュリティグループ（NSG）は新規でOKです。次に、DNS設定を行う為、Azureポータルでデプロイ完了を確認後、仮想マシンへのSSHログインを行う前に以下DNSゾーン設定を行います。
※この工程から、管理者（root）ユーザー、kusanagiユーザーなど、ユーザー別の仮想マシンへのＳＳＨ接続向けの鍵、パスフレーズ、パスワードなど各種の設定値は必ず全てメモしてください。かなり煩雑です。
DNSゾーン設定
Azureニューポータルに仮想マシンをたてる基本を見ながら独自ドメイン、もしくは、Azureの初期ドメインをkusaVM01の仮想マシン（バーチャルホスト）にDNSゾーン設定してください。
KUSANAGIの初期設定とプロビジョニング
KUSANAGIの初期設定 と KUSANAGIのプロビジョニング を参考にしながらkusaVM01について独自ドメインでブラウザからワードプレスの初期設定画面まで進んでください。データベースは、もう1台のKUSANAGI仮想マシンkusaVM02と接続するため、ワードプレスの初期設定画面から先には進まないでください。
DBサーバー用のKUSANAGI仮想マシンを立ち上げる
KUSANAGI仮想マシンをDB向けとして、Azureポータルからもう1台デプロイ構築します。仮想マシンの名前はkusaVM02とします。Resource Group（リソースグループ）は「RSG01」、ネットワークで「VNet01」、サブネットで「SBnet02」として間違わない様に選択してください。ネットワークセキュリティグループ（NSG）は新規でOKです。kusaVM02はインターネットから直でhttp通信することは無いため、DNSゾーン設定は行わず、KUSANAGIのプロビジョニングまで一気に行います。
※kusaVM01と同じように各種アカウントの設定値を必ずメモしてください。
ネットワークセキュリティグループ（NSG）の設定
ネットワークセキュリティグループ（Azure Fire Wall）の「kusaVM01-nsg」と「kusaVM02-nsg」が上記の仮想マシン2台を構築した時に自動で作られているので、それぞれサブネット（SBnet01とSBnet02）に割り当てます。「ダッシュボード」⇒「リソースグループ」⇒「RSG01」⇒「VPN01」⇒「サブネット」⇒名前「SBnet01」をクリック。「ネットワークセキュリティグループ（NSG）」で「kusaVM01-nsg」を選択し「保存」。
同じように「SBnet02」では、「ネットワークセキュリティグループ（NSG）」で「kusaVM02-nsg」を選択し「保存」。「ダッシュボード」⇒「リソースグループ」⇒「RSG01」で「kusaVM01」と「kusaVM02」の「ネットワークインターフェイス（NIC）」を見て下記の様な設定になっている事を確認してください。kusaVM02のプライベートIPアドレス（192.168.2.4）をメモします。
外部ホスト接続用のDBユーザーをkusaVM02へ作る
この操作はWEBアプリサーバーとDBサーバーを分離するために行う操作です。1仮想マシンの同一カーネル内におけるインバウンド（受信）の場合、操作の必要は無い事がほとんどです。仮想マシンのファイヤーウォール（iptables/firewalld）はカーネルの中にあります。標準出力とか標準入力とかのやつの話です。
kusaVM02へSSHでログイン。さらにMySQL（MariaDB）にrootでログインします。
//データベースにrootログイン mysql -u 'データベースユーザー名' -D 'データベース名' -p
そして、次のコマンドを実行、外部ホストによる接続を許可するMySQLユーザーを作ります。この時、新しく作るMySQLユーザーアカウントをしっかりメモしておいてください。※緩いMySQLユーザーを作っていますので、必要に応じて、IPアドレス制限など、セキュアなユーザーに変えてください。アクセス先とアクセス元を最小限に絞る事がセキュリティの基本となります。
//外部ホスト接続用のMySQLユーザーを作る grant all privileges on *.* to out_user@"%" identified by 'パスワード' with grant option;
受信セキュリティ規則/送信セキュリティ規則、NSG設定
DBサーバー「kusaVM02」について、「ダッシュボード」⇒「リソースグループ」⇒「RSG01」⇒ネットワークセキュリティグループの「kusaVM02-nsg」⇒「受信セキュリティ規則」に進む。以下の様にInternetとVirtualNetworkからの通信を全種Denyしつつ、SBnet01のkusaVM01（192.168.1.4）から受信するMySQLのTCP3306番の通信と自分で使うPCのIPアドレスによるSSHのTCP22番の通信として2つだけを許可していますが、必要な時以外、AllowMyIPのSSHはDenyに設定しておくことを強く推奨します。
受信セキュリティ規則のSSHとMySQLは、ポート番号を標準と別ものに変えておく
受信セキュリティ規則のSSHとMySQLは、ポート番号を標準品WellKnownPort（ウェルノウンポート）とは別でHighPort（ハイポート）に変えておく様なセキュリティ対策もあります。ググるとポートで30101番などのあたりが使われている例がよくあります。Azureの仮想ネットワーク内ファイヤーウォールであるNSG（ネットワークセキュリティグループ）に加えて、Linux仮想マシン側のファイヤーウォールであるiptables/firewalldの設定もあるので、合計2箇所のファイヤーウォール設定が必要です。見積の際にしっかり2箇所分を請求する必要が有ります。SSHのTCP22番やMySQLのTCP3306番へ直接攻撃をしてくるようなものについては門前払いできる様になります。
iptables/firewalld、仮想マシンのFirewall単品で見積思考をトレーニングするなら
iptables/firewalldのLinux仮想マシンのファイヤーウォール各種設定となると、事前に設定を書き出して、コマンドを作る作業が発生し、フラグを使ったステルススキャン対策、etc・・・もっとたくさん設定があります。時間と手間がかかる分、単品の作業として受注する場合は高めに設定する必要が有ります。エンジニアでない顧客の場合、顧客には技術ブラックボックスで説明は難儀を極める、単品見積で15万円などを提示すると、顧客が引いてしまって失注しやすいのが実態だと思います。悔しい悲しいIT業界。必ず、クラウド内の構築を全部まとめて受注して見積しないといけない。WEB appとかPaasって大事だなぁ。技術的な価値を考えると、作業単品受けで見積トレーニングするなら、コミュニケーション時間の消耗料金が入るので15万円でも安い、実際、慎重に考えて設定するだけで8h（1日）くらいはかかる（下手したら2日）。提出用の設定書面の作成で1日。全てコピペで終わらせるのはちょっと怖い。単品受注は現実的にありえないですし、受けてはだめですが、競合の人件費などを考慮/調査しながら利益も出せる見積を作られる能力を磨く事は大事。それが出来なきゃ給料は上げられない。工程一つ一つの価値を考えて、ミクロから各作業の料金を組み合せて全体の見積を行う能力は、赤字防止の大切なスキル、どこの会社でも欲しい特殊能力に近いかも。マクロ目線の人月どんぶり勘定も必要ですが、マクロとミクロの両方で考えられる能力は、商品パッケージ開発をする場合には非常に大切。1インスタンスのKUSANAGI運用であれば、カーネルのファイヤーウォールをいじる事はあまり無いと思います。
尚、セキュリティ規則の変更を行ってからAzure内で設定が反映するまで2～3分程度待ち時間が発生します。慌わてて検証すると失敗すると思います。セキュリティ規則の設定は、1つずつ設定が反映したことを確認しながら進んだ方がいいです。
ご参考に、規則を削除する時は、以下の様にすると出来ます。
同じようにkusaVM01も設定します。kusaVM01については、HTTPのTCP80番、自分のパソコンからのSSHのTCP22番の2つを開放し、他はすべて遮断します。kusaVM01も必要な時以外、AllowMyIPのSSHはDenyに設定しておくことを強く推奨します。セキュリティは、OSI参照モデルの7つのレイヤー全部を守る、すなわち全部を塞いで必要なところだけに穴をあける事が基本です。AWS/Azure/GCPなどのレイヤー1の物理層のセキュリティは、中小零細企業では実現不可能な領域だと思います、その点を考えると、管理の人件費も含めると結構お高い仮想マシンでも、お得感があると考えられるのではと思います。余談でした。
セキュリティ的には、送信セキュリティ規則の設定も環境に応じてしっかり行ってください、意外と大切です。またまた余談ですが、通常のWEBサイトではTCPを使い、マルチキャストやブロードキャストで動画のライブストリーミング配信を1対多として行う場合にUDPを使います。Azure Media Serviceなどが関係してきます。
kusaVM01にkusaVM02のDBを設定する
ブラウザでkusaVM01に設定した独自ドメインにアクセス、ワードプレスの初期設定画面に進み、kusaVM02の外部ホスト接続用DBアカウントを設定、MySQLホストにはkusaVM02のネットワークインターフェイスでメモをしたプライベートIPアドレス（192.168.2.4）を入力してください。その後、いつも通りのワードプレス設定を行って構築完了です。適当に記事を投稿し、kusaVM02のKUSANAGI仮想マシンにSSH接続してデータベースに記事が増えている事を確認してみてください。ついでに、kusaVM01のwp-config.phpでkusaVM02の外部ホスト接続用DBユーザーアカウントが設定されている事を確認してみてください。kusaVM02-nsg（ネットワークセキュリティグループ）でMySQLをDenyにするとブラウザでデータベース接続エラーが出れば正解です。
IPアドレスはNIC（ネットワークインターフェイスカード）に対して設定される
ネットワークを学習していないと、ホスト名に対してIPアドレスが割り当てられると考えがちですが、IPアドレスは各ホストに設定されたNIC（Network Interface Card）に付与されます。下記画像では、わざとNICを仮想マシンの右側に出して表現しています。有線LANの物理マシンであれば、ヒロセ電機のモジュラージャックTM21Rシリーズのすぐ後ろにNICが付いていたり、バッファローなどのサプライメーカーで、モジュラージャックとNICのセットモジュールでパーツが売られています。最近は見る事も無くなりましたが、無線LANカードもNICです。クラウドを扱うには、物理イメージが必要です。
1つのNICで複数のIPアドレスを設定する事なども出来、保守用のIPアドレスを別けたり、2つ目のApacheを割りあてたりなど、用途に応じていろいろできます。有線と無線のLANインターフェイスを両方内蔵し、NICが2つある物理マシンでは、1台で2つのIPアドレスが割り当てられています。DHCPサーバを探す流れとしてDHCPDISCOVERからDHCPACKまでの一連の流れを確認するとIPアドレスの割当てがよくわかります。
地理冗長について
Microsoft Azureは東日本/西日本リージョンがあり、国内の2拠点で冗長構成が可能です。アマゾンAWSは、2018年に国内は東京リージョン1拠点から大阪ローカルリージョンを加えた2拠点になりますが、大阪ローカルリージョンがオープン初期から東京リージョンと全く同じ機能を網羅出来るとは限りません。利用料は大差ないという事を考えると、国内で2拠点の冗長化構成を組みたい場合、現状、Microsoft Azureをお勧めします。
内容が脱線ばかりですみません・・・。
仮想マシンについて
障害ドメインや更新ドメイン≒データセンターで物理のラックや物理のコンテナ となるので冗長化を組む際に障害ドメインや更新ドメインの重複は避ける。
オンプレミスDBと接続する場合
Azureが持つ閉域網の Azure ExpressRoute と IPsecのVPN の2通りの方法がある。
Azure Load Balancer
ロードバランサーを使う場合、ポートの開閉で仮想マシンを監視している。仮想マシンの電源ON/OFFが判断基準ではない事に注意。また、WEBアプリサーバーとDBサーバーの間でプライベートIPアドレス（内部IPアドレス）を使って内部負荷分散（Internal Load Balancer:ILB）を行う事も出来る。配置箇所によってパブリックロードバランサーとプライベート（内部）ロードバランサーの2通りに別けて考える。
KUSANAGI仮想マシン2台停止で維持するといくら？
仮想マシン2台停止状態でも、仮想マシン1台につきディスク1つずつ毎月の請求が発生します。ディスクのサイズや数や仮想マシンサイズによって異なりますが、毎月で1500円×2など発生します。Azureバックアップやキャプチャなどスナップショット的なものを使う事をお勧めします。尚、その際、ネットワーク構成はバックアップされません。ネットワークなどインフラ構成の自動化は「Automation スクリプト」を活用する必要が有ります。
