2017年3月1日水曜日

Microsoft Azureのポイント対サイトVPNの設定

Microsoft Azureのポイント対サイトVPNの設定をGUIだけで行うことはできない、と思ってたんですができました。前からできたのか、最近できるようになったのかは未確認です。

これで「Microsoft AzureによるITインフラの拡張」でPowerShellが必要なのは、仮想マシンを一般化する部分だけになっているはずです。

やり方は以下の画面で値を入力し、[save]をクリックするだけです。

P2S-1
▲上の枠がアドレスプール、下の枠がルート証明書の設定

 

●アドレスプール

VPNインターフェース用のIPアドレス範囲です。サブネットマスクは24ビット以上が必要です。

ここでは、192.168.1.0/24を指定しています。

 

●ルート証明書

BASE64形式のルート証明書の本体(BEGIN/ENDを含まない範囲)を貼り付けます。ファイルを参照する機能はありません。

ここでは2つ目のルート証明書として指定しています。

1行しか枠がないところに、これだけの内容を貼り付けるのは不自然ですね。

2017-03-01 (8)
▲選択した部分をクリップボード経由で貼り付ける

2016年12月15日木曜日

社内の複数拠点からMicrosoft AzureにVPN接続する

Microsoft Azureで「社内の複数の拠点からVPNを張ってAzureのリソースを使いたい」と言われることがあります。

image

従来は、簡単な作業でなかったのですが、リソースマネージャーモデルであれば、以下のようにGUIだけで構成できます。リソースマネージャーでもVPNゲートウェイは1台しか作れませんが、複数の接続を簡単に追加できるからです。

まず拠点単位でローカルネットワークゲートウェイを構成します。ローカルネットワークゲートウェイは、オンプレミスのVPNルーターの情報を保存したものです。

次に、ローカルネットワークゲートウェイを使って、接続を追加します。

image

ここまでで、Azureと拠点A、Aureと拠点Bの接続が完了します。

マイクロソフトが提供するオンプレミス側VPNゲートウェイの構成スクリプトは、Azureの仮想ネットワークとローカルネットワークの範囲しかルーティングしないため、拠点Aと拠点Bの接続は構成されません。

これは、既存のルーティング情報に影響を与えないためです。そのため、Azureとの接続前から拠点Aと拠点Bが接続できている場合はそのまま使い続けることが可能です。

ただし、AzureのVPNゲートウェイ自体はローカルネットワークゲートウェイの情報を使ったルーティングが可能なので、オンプレミス側VPNゲートウェイで必要なルーティング情報を与えてやれば、拠点Aと拠点Bの接続が可能です。

以上の内容を図にしました。

image

同様に、ローカルネットワークゲートウェイのネットワーク範囲を追加すれば、オンプレミス側のネットワークも拡張できます。

なお、インターネット回線を通るため、拠点Aと拠点Bの通信にはそこそこ大きな遅延が発生します。

実際に、東京のトレーニングセンター内で仮想的に2つの拠点を作り、東日本のデータセンターにVPNゲートウェイを作って、拠点Aから拠点Bにpingを飛ばしたところ、10ミリ秒から25ミリ秒の遅延が発生しました(オンプレミスのルーターはWindows Server 2012 R2仮想マシン)。

連続して通信を行っても、遅延にはかなりばらつきがありました。決して品質が高いとはいえないのですが、インターネットにさえつながればどこからでも接続できるので、便利な状況もあるでしょう。

image

2016年12月13日火曜日

MCP資格と技術者バッジ

cclaimという会社がマイクロソフト認定技術者試験の認定結果を表示するサービスをはじめています。

スクリプトを利用して、改ざん防止をしているようです。

試しに付けてみました。見えるでしょうか。

2016年11月3日木曜日

BitLockerドライブ暗号化の修復

Windowsにはドライブ全体を暗号化する「BitLockerドライブ暗号化(BDE)」機能が備わっています。

TPMのない状態でBitLockerを有効にする

このBitLocker、現在はPCのハードウェアとしてTPM(Trusted Platform Module)が必要です。TPMが存在しない、あるいは無効になっている場合はBitLockerは使えません。それどころか、管理ツールすら表示されません。

TPMは、ハードウェア的なセキュリティ機能を持っており、安全な暗号化キー管理には必須の機能です。しかし、TPMがない場合でも、(セキュリティレベルの低下は承知で)パスワードなどを使った暗号化をしたい場合があります。

グループポリシーを有効にすることで、ソフトウェアベースの暗号化が可能になります。

BitLockerの制御は、以下のグループポリシーにまとめられています。

[コンピューターの構成]-[管理用テンプレート]-[Windowsコンポーネント]-[BitLockerドライブ暗号化]

OSのドライブ(通常はCドライブ)およびデータ用ドライブに対して、ソフトウェアベースの暗号化(TPMを使わない暗号化)を有効にするのは、それぞれ以下の項目を[有効]に設定し、[ハードウェアの暗号化を使用できない場合はBitLockerのソフトウェアベースの暗号化を使用する]を許可します。

  • [オペレーティングシステムのドライブ]
    -[オペレーティングシステムドライブに対するハードウェアベースの暗号化の使用を構成する]
  • [オペレーティングシステムのドライブ]
    -[スタートアップ時に追加の認証を要求する]
  • [固定データドライブ]
    -[固定データドライブに対するハードウェアベースの暗号化の使用を構成する]

GP-SYSTEM

設定を有効にするには再起動が必要でした。

以上の操作をすることで、BitLockerの管理ツールが有効になります(Windows Serverの場合はBitLockerの機能を追加する必要があります)。

仮想マシンにはTPMが存在しませんので、BitLockerを使うには、この操作を行う必要があります。ただし、Windows Server 2016およびWindows 10 EnterpriseのHyper-Vでは第2世代の仮想マシンで「仮想TPM」が利用できます。

 

暗号化キーが失われた場合の回復

BitLockerでは、以下の方法で暗号化キーを保存します。通常はTPMが必須、その他の方法はオプションです。

  • TPM
  • 起動時パスワード
  • USBメモリ(起動時に読み取り)

TPMはマザーボードに実装されているため、ディスク装置を別のサーバーに移動した場合は暗号化データを読むことができません。そこで、緊急用に、あらかじめ「回復キー」を保存しておきます。

回復キーは、BitLocker構成時に保存するように促されます。

  1. 1. [コントロールパネル]-[システムとセキュリティ]からBitLockerの管理ツールを起動
    BDE-START-0
  2. 暗号化したいドライブで[BitLockerを有効にする]をクリック
    (ここではデータドライブを選択します)
    BDE-START-1
  3. 通常の復号(暗号化データ読み取り)方法を選択
    (「自動的に解除する」がTMPを使う方法です)
    BDE-START-2
  4. 緊急時の回復方法を選択(キーの内容はどれも同じです)
    BDE-START-3
  5. このあと、確認を行って完了
  6. 暗号化したあとでも[回復キーをバックアップ]で、回復キーを取得可能BDE-START-4

回復キーはドライブごとに生成されるため、システムドライブとデータドライブでは別々に設定されます。必ず両方保存してください。

データディスクの回復手順

システムディスクに損傷があった場合、OSが起動できなくなります。この場合は、以下の手順で回復します。

  • データディスクを別のサーバーに接続
  • そのサーバーにBitLocker機能を追加
  • データディスクにアクセスし、回復キーを指定
    unlock-2

 

【参考】回復キーのバックアップで生成されるファイルは以下の通りです。

BitLocker ドライブ暗号化の回復キー

これが適切な回復キーであることを確認するには、次の ID の先頭と、PC に表示されている ID 値とを比較してください。

ID:

    5519409C-7AA4-435E-B336-F96BF5B4585C

上記の ID が PC に表示されている ID と一致する場合は、次のキーを使用してドライブのロックを解除します。

回復キー:

    627583-570284-183139-308693-097614-128656-683397-249128

上記の ID が PC に表示されている ID と一致しない場合、ドライブのロックを解除するための適切なキーではありません。
別の回復キーを試してみるか、http://go.microsoft.com/fwlink/?LinkID=260589 で詳細を確認してください。

2016年10月24日月曜日

Hyper-V仮想マシンからAzureへのフェールオーバーとフェールバック

Microsoft Azureは、オンプレミスのサーバーをAzureに複製(レプリケーション)し、必要に応じてフェールオーバー(障害時の切り替え)ができます。ただしHyper-VホストはWindows Server 2012 R2が必要です。

Windows Server 2012 R2のHyper-Vホストは以下の仮想マシンをサポートします。

  • 第1世代(BIOS)および第2世代(UEFI)の仮想マシン
  • VHD形式およびVHDX形式の仮想ディスク

一方、Microsoft Azureがサポートする仮想マシンは以下の通りです。

  • 第1世代(BIOS)
  • VHD形式の仮想ディスク

そのため、Hyper-Vの第2世代は第1世代に変換され、VHDX形式はVHD形式に変換されます。この処理は自動的に行われるため、特に作業は必要ありません。

一方、フェールバック(Azureで起動した仮想マシンをオンプレミスに戻す)時は注意が必要です。

大規模災害などで、データセンタが破損したあと、システムが復旧したとします。この場合、Azureから「フェールバック」を行うことで、元のシステムを復元できます(操作メニューは「フェールオーバー」を使います)。

オンプレミスの仮想マシン存在しなくても「オンプレミスにVMを作成する」オプションを指定すれば、自動的に復元します。

計画フェールオーバー2

この時、Azureから戻ってきた仮想ディスクはVHD形式に変換されたままですが、容量可変ディスクに戻ります。以前の状態を覚えているのでしょうね。

ただし、フェールバック(Azureから戻す)で、Azureの(変換された)第1世代PCを(元の)第2世代に戻すことはできません。しかし、どうもAzureは第2世代に戻そうとするようです。こちらも以前の状態を覚えているようですね。

もちろんこの作業は失敗するため、第2世代の仮想マシンを戻す(フェールバックする)ことはできません)。図のエラーはそれを示しています。

本記事の内容は「Microsoft Azureによる災害復旧手法 ~Azure バックアップとAzure Site Recoveryでの仮想マシン保護~」で扱っています。

2016年8月23日火曜日

NFC0202G

特徴的なクラウド事例やインタビュー記事を集めてきました。

【クラウドの基礎】

 

【クラウド利用事例】その1

 

【クラウド利用事例】その2

 

【クラウド利用事例】その他

  その他にもこんなものがあります。

 

【開発と運用のアーキテクチャ】

DevOpsなど、開発と運用についてのインタビュー記事です。

【その他資料】

Amazon Web Services編

 

Microsoft Azure編

2016年8月16日火曜日

Microsoft Azureの演習中に起きたトラブル

最後の演習中、Microsoft Azureの管理ポータル(クラシックポータル)が不具合を起こしました。終了時刻が近付いていたので不本意ながら中断して、口頭での解説だけを行いました。

あとで見たら、エラー報告が上がってました。

最後の、一番大事な演習だったので残念でした。受講者の皆様には、サポートサービス「グローバルスクエア」の質問回数制限を緩和させていただきます。

ご迷惑をおかけしました。

通知ログ