Azure StackのPEP(privileged endpoint, 特権エンドポイント)へどこから接続すべきか

Azure Stackではログ収集や一部の操作を行うためにPEP(privileged endpoint, 特権エンドポイント)に接続するケースがあります。個人的に一番多いのはTest-AzureStackコマンドでテストすることでしょうか。 そのPEPにはRemote PowerShellで接続するのですが、そこに対してどこから接続すべきか、というガイドラインが当初と大きく変更されていますので少々注意が必要です。 - [Azure Stack での特権エンドポイントの使用 | Microsoft Docs](https://docs.microsoft.com/ja-jp/azure/azure-stack/azure-stack-privileged-endpoint) 上記の最新のドキュメントでは下記の説明が記載されています。 注意 セキュリティ上の理由から、PEP への接続は、ハードウェア ライフサイクル ホスト上で実行するセキュリティを強化された仮想マシンから、または Privileged Access Workstation のような専用のセキュリティで保護されたコンピューターからに限定して行う必要があります。 ハードウェア ライフサイクル ホストは、元の構成から変更しないようにするか (新しいソフトウェアのインストールするなど)、または PEP への接続に使わないようにする必要があります。 HLH(ハードウェアライフサイクルホスト)から直接接続するのではなく、その上で動く仮想マシンや専用のPCからの接続が推奨されています。 これ、実は当初はHLHから直接接続することが推奨されていたんです。このことは過去の編集履歴を参照するとわかります。 - [adding update · MicrosoftDocs/azure-docs@a0826e6](https://github.com/MicrosoftDocs/azure-docs/commit/a0826e6e56975c80572d9867ab19a7573d75fef5#diff-191bf0c6135f0e9c0ec5d08b7ec9c30f) ドキュメントがGithub上で管理されているので過去の履歴も追いやすくて良いですね。 これからAzure Stackを利用する場合にはどうということもないのですが、HLHから接続するようにしていたところ、ある時からPEPに接続ができなくなっていてこの事に気が付きました。 OEMのUpdateを適用する中でHLHへのセキュリティ設定が変更され、HLHからPEPへのRemote PowerShellでの接続も禁止されたようでした。 同様の変更は今後は発生しないとは思いますが、いつものことながら英語の最新版のドキュメントを参考にするのが色々と良さそうです。

August 26, 2018 · 1 min · 胡田昌彦

AnsibleでWindows VMの構成

今日は先日作ったTerraformファイルで作成したAzure上のVMに対して、先日作成したAnsibleが動作するコンテナ上でAnsibleのPlaybookを書いて、VMを構成してました。 - ドメインコントローラーに昇格(新規フォレスト作成) - 必要に応じて再起動 - StandAloneRootCAに構成 - 必要に応じて再起動 - サブジェクトの別名を利用可能に構成 - Azure Stackに必要な証明書のためのCSRを作成 というところまで自動化しました。 変な所で色々とハマりましたが、結局目的のところまではできたので良かったです。VMをAzure上にイチから作成するところから含めて全部やり直しても構築時間で15分もかからない感じに収まってます。 他にもDocker for WindowsをつかってLinuxコンテナを利用したり、実PCのファイルシステムをマウントしたり、Dockerfileを使ってのビルドをローカルPCとGitHub連携したDockerHub上でおこなったりというところもずいぶん慣れました。 ansibleでPSCredentialを渡す所でxxxx_username, xxxxx_passwordという形で表記しておけばよいだけとマニュアル上で読んだのですが、実はxxxxの部分に使う文字列によって挙動が異なるように見える部分があってかなり時間を無駄に消費しました。一部スペルミスもあったりなどもあり。よくわからないエラーが出たときには一度クリーンなところまで戻ってから文字をコピペせずに慎重に打ち直そう…と思ったのでした。 ansibleからPoweShellDSCを利用する部分も理解しましたし、昨日、今日で結構Terrafrom + ansible(+ PowerShell DSC)の組み合わせには慣れた気がします。 というわけで今日の成果はこちら。 - [https://github.com/ebibibi/hccjp/tree/master/VMConfigure](https://github.com/ebibibi/hccjp/tree/master/VMConfigure) 明日と明後日は贅沢に丸々2日間Puppetのトレーニングです!楽しみです。

July 18, 2018 · 1 min · 胡田昌彦

ansibleが使えるコンテナイメージ

TerraformでWindowsVMを展開した後はansibleで構成を自動化しようと考え中です。 Windowsからの管理は現実的に無理みたいなので、仕方なくDocker for Windows上のLinuxコンテナで管理しようとかんがえています。 ansibleの公式イメージをpullすれば瞬殺だろうと思ったのですが以下のあたりはもう公式ではイメージメンテナンスされてません、ということだったのでそのままの利用を躊躇してしまいました。 - [ansible/ubuntu14.04-ansible - Docker Hub](https://hub.docker.com/r/ansible/ubuntu14.04-ansible/) - [ansible/centos7-ansible - Docker Hub](https://hub.docker.com/r/ansible/centos7-ansible/) で、勉強も兼ねて自分でDockerfileを書きました。(あまり根本的解決になっていない気もしますが) - [ubuntu_ansible/Dockerfile at master · ebibibi/ubuntu_ansible](https://github.com/ebibibi/ubuntu_ansible/blob/master/Dockerfile) Dockerfile作成中には「pip install –upgrade pip」というコマンドも入れていたのですがこちらはpipの9と10のバージョン違いによるトラブルが発生してしまいうまく行かず。結局pipのアップグレードはやらないことにしました(逃げ)。 このあたりは下記ブログに解説されていました。 - [pip install --upgrade pip (10.0.0) 後の奇妙な挙動について - 雑記](http://icchy.hatenablog.jp/entry/2018/04/17/064443) 助かりました。ありがとうございます。 というわけで、Dockerイメージも準備できました。 - [ebibibi/ubuntu_ansible - Docker Hub](https://hub.docker.com/r/ebibibi/ubuntu_ansible/) 次は、このコンテナを利用して、Azure上に展開したWindowsVMを自動構成する予定です。明日時間取れる予定…! 業務時間にこうやって自分がやりたい領域のことを勉強しながら作業できるのは本当にありがたいです。(注意:遊んでいるわけではありません。仕事です。)

July 17, 2018 · 1 min · 胡田昌彦

TerraformでWindowsVMを作成する

今日はTerraformでWindows VMを作りました。 LinuxVMの作成サンプルとほぼ変わりませんが、一部展開後にAnsibleで管理される準備を自動実行させるぶぶんだけ工夫してみました。Terrafromでブートストラップしてから、ConfigurationはAnsibleで管理…、に自然に移行できるようにしているつもりです。 Ansibleでの構成はこれから試すので、できる想定…なのですが。 Terraformの作成サンプルはLinuxVMばかりでWindowsVMの例があまりないので少しは参考になる部分があるかもしれません。 - [https://github.com/ebibibi/AzureManagement/tree/master/Terraform/CreateWindowsVM](https://github.com/ebibibi/AzureManagement/tree/master/Terraform/CreateWindowsVM)

July 17, 2018 · 1 min · 胡田昌彦

Azure AD B2Bでユーザーを招待し、Azureサブスクリプション上で単一RGにのみ権限を付与する

最近あるAzure Subscriptionに対して個別のユーザーに個別のRGのみ作成して権限を割り当てるということを都度都度行う必要が出てきました。 海よりも深い事情があり、普段利用している組織アカウントにはAzureサブスクリプションを紐付けられない理由があり(EA契約に紐付いているのでEA契約にコンバートされてしまう)、仕方なく別AADに紐づけて作成してあります。 でも、Azure環境は普段利用している組織アカウントを限定的な権限および範囲で使ってほしいため…以下のような作業をすることにしました。 - Azure AD B2Bで別のAADの組織ユーザーを招待する - 招待したユーザー用にリソースグループを1つ作成する - 作成したリソースグループに招待したユーザーを共同作成者としてアサインする 手作業だとちょっと時間かかりすぎるのと、繰り返し何人も都度都度対応する必要があるので、PowerShellスクリプトを書きました。 - [https://github.com/ebibibi/AzureManagement/blob/master/AAD/InviteUserWithAADB2B.ps1](https://github.com/ebibibi/AzureManagement/blob/master/AAD/InviteUserWithAADB2B.ps1) 外部テナントのユーザーを招待した直後に権限を割り当てて大丈夫なのかちょっと不安でしたが、どうやら意図したとおりにうまく動いているようです。

July 13, 2018 · 1 min · 胡田昌彦

Microsoft MVP for Cloud and Datacenter 再受賞しました

表題の通り、Microsoft MVP for Cloud and Datacenter を再受賞させていただきました。2014年4月に初受賞させてもらってから結構長い期間になってきました。 - 2014/4 Windows Expert-IT Pro - 2015/4 System Center and Datacenter Management - 2016/4 System Center and Datacenter Management - 2017/7 Cloud and Datacenter Management - 2018/7 Cloud and Datacenter Management 2017年7月の受賞時点ではもう更新は諦めていたのですが、現時点では環境とモチベーションもかなり復活しております。 私自身はMicrosoft MVPでありながら平日夜も土日も子供優先でコミュニティの勉強会にも全く参加しないかなり異端な存在だと思うのですが、仕事と紐付いた形で企業内や、企業の枠を超えたコミュニティ活動を行なっており、この路線であれば今後も継続できるなと思ってます。 人生の優先順位付け、自分の時間の投資先の選択は難しいですし、一度決めても人生ステージの変化に従って変化させていかなければいけないです。受動的な取り組みであっても魂を揺さぶられるほどのものもありますし、価値観の相違で周りの理解が得られない事も多々あります。本音と建前もありますし、色々と悩ましいところもありますが、こうして何かしら「活動を認められて、賞を受賞する」と形に残せるのは大変ありがたいです。 来年も受賞できるように頑張りたいと思います。

July 2, 2018 · 1 min · 胡田昌彦

Windows UpdateしたらRDPできなくなってしまって困っている方への回避策

随分前から話題になっていましたが、まだ回避できていない方がいるようなので私が現在取っている回避策を紹介しておきます。 Windows Updateによって規定のセキュリティレベルが高まり、その影響でRDP接続できなくなる…という事象ですね。 とりあえず上記のようにローカルコンピューターポリシーをいじってしまえばUpdateされていないWindows Serverに対してもRDPが可能となります。 もちろん「脆弱」でありずっとこのまま運用してよいわけではありませんので、きちんとサーバーもクライアントもUpdateをして回ってもらえればと思います。 なお、私自身は出会っていないので詳細なエラーメッセージですとかパターンがわかっていませんが下記のようなエラーメッセージが出るようです。 認証エラーが発生しました。 要求された関数はサポートされていません 原因は CredSSP 暗号化オラクルの修復である可能性があります。

May 30, 2018 · 1 min · 胡田昌彦

TerraformをつかってAzureにLinuxVMを作成してみました。

先日に引き続きTerraformで遊んでみました。とはいえ、まだWebにあるチュートリアルをそのままやってみているだけですが。 - [Use Terraform to create a complete Linux VM in Azure | Microsoft Docs](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/terraform-create-complete-vm) VSCode上で"Open Bash in Cloud Shell"を使って実行しています。 ほぼサンプルそのままで試したのですが、SSHの公開鍵の部分は自分のものにする必要がありました。 VSCode上のCloudShellでsshの鍵を生成する方法は以下を参照しました。 - [Azure での Linux VM 用の SSH キー ペアの作成と使用 | Microsoft Docs](https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/mac-create-ssh-keys) ssh-keygen -t rsa -b 2048 でキーペアを作成して、生成された公開鍵/home/mebisuda/.ssh/id_rsa.pubを指定しました。 あとは、いつものように、terraform init, plan, applyを実行すればOK。 今回は配置場所を東日本リージョンに変更していたのですが、編集を一部間違えて存在していないリージョン名を指定してしまいました。それでファイルを編集後にAzure Terraform: pushコマンドをVSCode上で実行しておらず、「なんで修正したのに反映されないんだろう?」とちょっと悩んでしまいました。 cloudshellの概念をきちんと抑えないといけないですね。 VSCode上で使っているCloudShellもAzureポータル上から使うcloudshellも同じものであり、リモートの環境である、ということを理解しました。(実装の理解としては間違ってるかもしれませんが、概念としてはあってると思います。) というわけで、仮想マシンを無事作成して、SSHで接続することができました。 最終的に利用したテンプレートは以下です。 - https://github.com/ebibibi/AzureManagement/blob/master/Terraform/Demos/CreateLinuxVM/createlinuxvm.tf とりあえずTerraform on Azure(っていう表現でいいのかな?)の基本は理解したと思います。あとは、ドキュメントを参照しながら試行錯誤でテンプレートを作成できるところまでは来ました。 次はいくつかサンプルを読み込んでみようと思います。 Terraform examples for Azure

May 23, 2018 · 1 min · 胡田昌彦

TerraformでAzureをいじってみました。

TerraformでAzureをいじってみたい、ということで超簡単なところから触ってみています。 - [Download Terraform - Terraform by HashiCorp](https://www.terraform.io/downloads.html) よりバイナリダウンロード。とりあえずWindows版の64bitのバイナリをダウンロードしました。 - パスの設定。exeファイル1つだけなので、どこからでも使えるようにDropbox上に格納してそこにPATHを通しました。 - 環境を整える際のサンプルスクリプトがAzure CLIなのでAzure CLIの環境を整えます。 - Install the Azure CLI for Windows | Microsoft Docs よりMSIでAzure CLIをインストール - Visual Studio Code上で色々やろうと思うので、Azure CLI系やTerraform系の拡張を言われるがままに入れる。 Azure CLI Tools - Azure Resource Manager Tools - Azure Terraform - Terraform - 単純にリソースグループを作成するだけのtest.tfで試してみる provider “azurerm” { } resource “azurerm_resource_group” “rg” { name = “testResourceGroup” location = “westus” } テキストファイルを用意しておいて terraform init, plan, applyコマンドをそれぞれ投入するだけできちんと意図した状態になることを確認できました。素敵ですね。コンフィグファイルが読みやすくわかりやすいのが素敵です。そして、Visual Studio Codeがずいぶん素敵ですね、言われるがままに操作するだけで勝手に環境が整ってしまいました。 mebisuda@Azure:/clouddrive/AzureManagement/Terraform/Demos$ az group list [] mebisuda@Azure:/clouddrive/AzureManagement/Terraform/Demos$ terraform init ...

May 22, 2018 · 3 min · 胡田昌彦

古いAzureStackのアプリケーションをAADから削除する

ASDKを毎月デプロイしていると、AADの中にAzure Stackのアプリケーションが沢山できてしまいます。最新のものを残して古いものを削除する為のスクリプトが無保証で参考に公開されていましたので、共有します。 - [AzureManagement/CleanAzureStackAADApps.ps1 at master · ebibibi/AzureManagement](https://github.com/ebibibi/AzureManagement/blob/master/AzureStack/CleanAzureStackAADApps/CleanAzureStackAADApps.ps1)

May 18, 2018 · 1 min · 胡田昌彦

(主にインフラ系エンジニアから見た)コーディングやスクリプティングに関しての流れ

主にインフラエンジニアからみて、過去から現在までの流れ…のようなものを私が見えている範囲で記載してみました。昨今はクラウド化の流れと相まって非常に高度な自動化やインフラのコード化まで実現可能となっており例えば「スクリプトも書いたことありません」という人に対してどの領域から飛び込んでもらうのが効率的か…をちょっと悩んでいます。 もうコーディングレスでLogic Appとかそういうところに飛び込んでもらった方がはやいのかもしれないし、仮想基盤のことやWindows, Linuxの中の事はすっ飛ばしてTerraformとかコンテナとかそこに注力するところから入って必要が出たところで仮想マシン内部の処理に入ったほうがいいのかもしれません。でも、現実的にはシェルスクリプトとかPowerShellスクリプトの基礎とかは抑えておかないとだめかもしれないし・・・。結構悩ましい所です。 - 昔はバッチファイルやシェルスクリプトで繰り返し実施する作業の効率化がありました。 - その後Windows的にはWSHの時代があり、vbscriptでスクリプトを書いたひとも多かったと思います。 - その後Microsoft的にはコマンド毎にオプションが違ったりコマンドがなかったりすることを解決し、全て統一するものとしてPowerShellを生み出しました。(私の大好きな[Jeffery Snover](https://twitter.com/jsnover)さんの仕事です。) - これでMicrosoft系はPowerShellで全てオブジェクト指向の管理となりました。(バックグラウンドにあるのは.net framework) - 一方UNIX系は当初からなんでもかんでもテキストであるという思想でした。 - MicrosoftはPowerShellを標準として様々な製品を開発しました。GUIではできないことでもPowerShellでなら操作できる。GUIで操作しても裏ではPowerShellコマンドが自動生成されてそれが実行されている…というものも多くありました。(結果、仕方がなくPowerShellを使うようになった方も多いと思います。) - Microsoftはクラウドサービスにもその流れを取り入れました。PowerShellにてクラウドサービスの管理も行うことになりました。 - Chef, Puppetなどに代表されるような冪等性を備えた仕組みが登場してきました。(Infrastructure as code, Configuration as code) 何度実行しても「記載した望むべき状態になる」ことを特徴とします。 - これ以前は「これを実行したらこうなる、やって見る前に状態を確認して、やってみて、やった結果を確認する」というような作業の流れを記述するようなイメージでした。 - MicrosoftもPowerShell DSCにて冪等性を持つフレームワークを提供しました。 - Microsoftのオープンソース指向が進む中でよりマルチプラットフォーム化を意識した取り組みがなされるようになっていきます。 - PowerShellの継続開発が打ち切られ、PowerShellCoreに舵がきられます。PowerShellCoreはWindowsだけではなく、Linux, Mac等でも動作するマルチプラットフォームなPowerShellです。(バックグラウンドにあるのは.net core) - AzureにもCloudShellの機能がつき、ポータル上でもコードで制御できるようになります。これまでのAzure PowerShellよりも先にAzure CLI(UNIX系の文化)の方が先に搭載されました。Azure管理はPowerShellよりもCLIの方が優先されるようになってきています。 - クラウドサービスも普及する中で、大規模な環境ではもう個別に1台づつターミナルで作業するなり、RDPではいってGUIで操作するなりすることが現実的に不可能な規模になりました。このような環境ではコードで全てを制御可能な環境にすることは必須条件となりました。 - WindowsもWindows Server Coreが出てGUIがなくなり、さらにNano Serverにてどんどん軽量化していきます。 - Windows Server 2016, 2019となると継続的に進化するモデルはGUIが利用できなくなりました。 - 更に軽量化を推し進める中で仮想マシンではなく、コンテナに大きくトレンドが傾きます。 - コンテナの標準であるDockerはDockerfileというコンテナをコードで定義できる機構を備えています。 - クラウドサービスも冪等性をもったテンプレートにて展開可能な構造となります。AzureであればARMテンプレート、AWSであればCloud formationなど。 - ARMテンプレート、Cloud formationによるInfrastructre as Codeと仮想マシンの内部を構成するChef, Puppet, AnsibleのようなConfiguration as Codeによって仮想マシンベースの環境構築の完全自動化が可能となりました。 - ARMテンプレート、Cloud formationによるInfrastructre as CodeとDockerによるコンテナコントロールで完全自動化が可能となりました。 - 複数のコンテナプラットフォーム自体のコントロールという観点ではKubernetesが標準化してきています。 - AWSLambda, Azure Fuctionsのようなインフラ自体を意識せずアプリケーションロジックのみを記載すればそれでおしまいとなるようなサービスも出てきました。ここではInfrastructure as CodeやConfiguration as Codeすら必要ない世界があります。(これですべてまかなえるわけでもないですが) - DevOpsという流れもありますが、NoOpsに向かう流れの方が強そうに感じています。(私の感想) ※NoOpsはインフラ管理者がいらないという意味ではなく、極力インフラの面倒を見なくていいアーキテクチャを採用する、くらいの意味で捉えています。 ...

May 16, 2018 · 1 min · 胡田昌彦

Azure Stackは超先進的である(MS高添さんと一緒に登壇させてもらいました)

本日のセミナーにてMS高添さんと一緒に登壇させてもらいました。別のセッションでそれぞれ登壇…ではなくて、2人で前にたってセッションを進めさせてもらいました。ずっと高添さんと一緒にやりたかったのでやれてよかったです。 想像していたよりも私が高添さんに助けてもらうばかりになってしまいましたが、それでも楽しかったです。 さて、本日のセミナーではシステムアーキテクチャやサービス形態の変化を振り返りながら、Azure Stackがどれだけ先進的なのか、という話をさせてもらいました。 システムアーキテクチャとしては今「ハイパーコンバージド」が流行していて非常に引き合いの強さを感じているのですが、Azure Stackはハイパーコンバージドも内包しながらさらに様々なものがサービス化されています。もちろんポータルも完備されていますし、各種APIもそなえています。そしてそれはAzureとも互換性があるものです。 さらに、Azure Stackはサービスとしてのカバー範囲は仮想化の一歩先を行く「IaaS」から「PaaS」はもちろん、コンテナの管理基盤(CaaS)、サーバーレスアーキテクチャ(FaaS)もカバーします。 この図は最近書き直したのですが、以前はIaaS, PaaS, SaaSというクラウドの形態を紹介するために作成しましたが、改めて作り直してやはり今ではCaaS, PaaS, FaaSにイノベーションが多く起こっていることを実感しています。そしてオンプレミスに機器を置くAzure Stackでもこれらがカバーされる…常識を入れ替えて対応する必要を改めて強く感じています。 セミナーでも会話しましたが、このブログが動いているのは15年くらい前からずっと運用し続けているLinuxの仮想サーバーなのですが、最近新しく作った以下のサイトはCaaS, PaaS基盤を使うようにしていまして、日々の面倒なことから解放されて大変に幸せな感じです。 - [このサイトの構造について(Web App for Containers) | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e3%81%93%e3%81%ae%e3%82%b5%e3%82%a4%e3%83%88%e3%81%ae%e6%a7%8b%e9%80%a0%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6web-app-for-containers/) 自分で新しいシステムを作るならもう仮想マシンベースでは考えたくないくらいのところまで私の感覚は来ています。 クラウドを「構築する」のではなく、「使う」人の為のシステムであるAzure Stack。私が登場時に受けた衝撃はまだセミナーに来てくださっている方やお客さんに伝えきれていない気がしますが、引き続きこのような活動はしていきたいと思います。 なお、4月から会社での役職が代わりシニアエキスパートとしてより技術的な面にも時間を割けるようになる予定です。本も出したいです。それもあって新しいサイトも新しい仕組みで作ってみたりしています。このブログの更新頻度も上がる…予定です。

April 16, 2018 · 1 min · 胡田昌彦

マイクロソフトアカウントを新規に作成すると対応するAADテナントと組織アカウントも作成されていた!

このあたり追いかけていない人には何のことかわからないと思いますが、個人的に衝撃だったので簡単にブログにポストします。 - マイクロソフトアカウントを作成すると、そのユーザー名とメールドメインに紐付いて自動的にAADテナントが作成されるようになっていました! - しかも、そのAADテナントには**マイクロソフトアカウントに紐づけたメールアドレスがユーザー名である組織アカウント**が自動作成されています! 上記がその証拠画像です。 いつからこうなってたんでしょうか?マイクロソフトアカウントを作成するときにAADにすでに登録済みのドメインのメールアドレスは使えないようになったのはずいぶん前ですが、この条件であればこうできるのかな?という感じではありますが。 マイクロソフトアカウントはAzureからみると以前はAADには紐付かない宙ぶらりんなアカウントでしたが、今はAzure利用という観点でみるとしっかりとAADにも紐づく存在になってきているようです。 もっとも、新規作成のマイクロソフトアカウントはこの状態だとしても、以前から存在しているマイクロソフトアカウントはまた違うようですが。 それにしても、AADに追加した確認済みのドメイン名ではないドメインの組織アカウントがディレクトリ内に存在する状態にしてしまって、ほかとの整合性は大丈夫なんでしょうか?ちょっと心配な部分もありますが、うまくさばいてくれることを期待しながら…。 なお、このようにマイクロソフトアカウントもAADに紐付いたので、サブスクリプション転送時にもディレクトリの切り替えが発生するパターンが増えていますね。このあたり諸々注意が必要です。 個人的にはもうマイクロソフトアカウントも全部完全にAADのアカウントです、という形で整理してくれた方がスッキリする気がしますが…。

April 12, 2018 · 1 min · 胡田昌彦

パスワードは無期限にすべき/「クラウドにパスワードを置くのは危険」は二重に間違い

過去から何度も言われていることですが、パスワードは無期限に設定したほうがセキュリティ対策上好ましいです。(反対派も根強く存在しますが) 先日、Office 365の管理者画面に久しぶりにアクセスしたところ、推奨事項として簡単にパスワードを無期限に設定できるようになっていました。感動してTwitterに投稿した所、3000回近くリツイート、お気に入り登録がなされました。 マイクロソフトがついにパスワード無期限を推奨事項としてO365の管理画面に出してくれた!!素晴らしい!!! pic.twitter.com/GqRNv7uOqu — Masahiko Ebisuda (@ebi) 2018年2月27日 個人的には過去最高のTwitter上での反応でした。それだけパスワードの定期変更が設定され、それに不満を持っている人が多いということなのだと思います。 ただ、画像のメッセージ上では「ユーザーアカウントをクラウドで管理している場合は、パスワードを無期限に設定することをお勧めします。」という表現になっています。 「これを推奨する理由の詳細を表示」のリンク先は下記のアドレスをなっており、そこではオンプレミス、クラウドにかかわらずパスワードの定期変更は良くないこととして解説されています。 - [Password Guidance - Microsoft Research](https://www.microsoft.com/en-us/research/publication/password-guidance/) それでも、あえてOffice 365上の管理画面にて「クラウドで管理している場合は」という書き方をしているのかと言うと・・・、そこにはAzure Active Direcotryが備えているセキュリティ対策機能の存在があるからだろうと思いますし、ADFSを使わずにAzure Active Directory上でユーザー認証を可能な状態にしてほしいという思想が表現されていると思います。 以下は私の推測や考えも混じっていますので全部そのままうのみにはしないでいただきたいのですが… まず、Azure Active Directoryの開発者はクラウド上でユーザーを管理する事、つまりパスワードハッシュもAzure Active Directory上まで同期する構成を強く推奨しています。(これは本当です。直接聞いてます。) そうすることによって、脆弱なパスワードを設定しているユーザーは一発で判別できますし、怪しい挙動をしているユーザーをAzure Active Directory側で検知できます。 オンプレミスのActive Directoryで適当な管理をしている状態よりもAzure Active Directory上で管理したほうが遥かにセキュアにできるんです。 わたしはこれは自明なことだと思います。だって、Azure Active Directoryからユーザーデータベースを引っこ抜くのと、オンプレミスのActive Directoryからデータベースを引っこ抜くなり、DCのイメージを盗み出すなりするのと、どちらが簡単でしょうか?圧倒的に後者の方が簡単ですよね。というか、前者はできる気がしないです。 よく「クラウドにパスワードを置くのはセキュリティ的に危ない。だからADFSをつかってオンプレミスにパスワードを置く。」という言い方をする人がいますよね。これ、二重の意味で間違っています。 まず、そもそもパスワードってどこにも置かれていません。パスワードがそのまま生で暗号化もハッシュ化もされずに置かれているなんてとんでもなく間違った設計です。危険なんてもんじゃなく、ひどすぎます。 たしかに、「パスワードを忘れた」ボタンをおしたらメールで生のパスワードを教えてくれるWebサービスは存在します。残念ながら。ですが、それはあまりにもひどすぎる実装なのであって、そもそもそんなサービスをつかってはいけないと言っても過言じゃないくらいのひどい実装です。(だから、パスワードは全部違うものにしましょうね。) パスワードはそのまま生で保存しては大変に危険なので、そのままは保存しないのが鉄則なんです。パスワードを生で保存しなくても正しいパスワードを入力したことを調べる術というのはきちんと存在していて、パスワードのハッシュ値を保存しておき、ユーザー認証時のパスワード入力に関してもそのハッシュ値を比較し、同一であれば正しいパスワードが入力されたということが判断できます。あるいはそもそもパスワードを必要としない実装にする方法もありますね。 なので、そもそも「パスワード」そのものはどこにも置かれていないのです。頭の中にあるだけです。その辺の紙に書かないでくださいね。(パスワード管理ソフトに可逆変換状態で保存されるのはありだと思います。) そして、ADFSを使ってオンプレミスのADで認証を行った場合は、セキュリティ的にAzure Active Direcotryで認証させるよりもセキュリティ的に強固であるという主張の根拠が私には全くわからないです。 たとえば、外部からのアクセスは全部ブロックしてるんです…というのでも、それAzure Active Directoryでもできますしね。マイクロソフトが物凄い数の世界中の組織のIDを束ねて超厳格に管理してくれているAzure Active Directoryと、自前で構築しているADFS + Active Directoryとを比較して「うちの組織の認証システムはMicrosoftよりもイケてる!」と言えるって凄い自信だなと思います。これって製品コードだけではなくて、運用面等まですべて含めての話ですからね。 それで、Azure Active Directoryを前提とした時に「パスワードは無期限に設定したほうがよい」というのは真だと思います。 オンプレミスのADFS + Active Directoryに関しては「やられてるんだけど気がついてません。」という状況の時にパスワード変更を行ってその結果、セキュリティ対策的に意味があるものになる…という可能性は無いことは無い(そもそも前提からおかしいんだけど)という感じには思うわけです。 そもそもは、パスワードを十分に長くて複雑なものにしておけば良いわけです。そして、その上でパスワードが盗まれても大丈夫なように多要素認証にもしておくべきです。さらにさらに、ユーザーの挙動をみて、怪しいものはブロックもできるようにしておけばさらに安心ですし、ルールを守れず脆弱なパスワードを付けてしまう人も一定数いるでしょうからそれは設定できないようにブロックしたり、設定されてしまっているものは洗い出せるようにすべきです。冗長化、負荷分散もしっかりとしていないといけませんね。インターネットに公開されている認証の窓口なので、攻撃も沢山くるでしょう、それも検知してブロックしなければですね。DDos攻撃だってくるでしょう、それも対処可能でなければいけません。Azure Active Directory(+ Premium P1, P2)ならこれ全部やってくれます。この前提の中では当たり前にパスワードは無期限にして、ユーザーに正しく複雑なパスワードを設定してもらうのが良いですね。 ...

March 4, 2018 · 1 min · 胡田昌彦

Azure MigrateがGAしています

Source: Confidently plan your cloud migration: Azure Migrate is now generally available! | Blog | Microsoft Azure Azure MigrateがGAしてますね。 システム間の依存関係を可視化するServiceMap(OMSに入ってるやつ)が無料で使えるそうです。 No charge for dependency visualization: Visualize network dependencies of your multi-tier application without getting charged for Service Map. 一歩進んだアセスメントサービスをするのには非常に有用なツールになってると思います。 さらにVMWareの対応が先でHyper-V環境は今後対応する、というのが生々しくて良いですね!今のMicrosoftらしさが出ていると思います。 It enables discovery of VMware-virtualized Windows and Linux VMs today and will enable discovery of Hyper-V environments in the future.

March 1, 2018 · 1 min · 胡田昌彦

Azure Stackのロードマップ

Source: Azure Roadmap | Microsoft Azure Azure Stackに関してのロードマップが出てますね。(Azure roadmapにてAzure Stackのタグでフィルタ) 以下ざっくりとした拙訳です。 予告通り最大16ノードのスケールユニットへの拡張が開発中- Azure Stack上のゲストOSやデータディスク、ボリュームのAzure Backupを使ったバックアップおよびリカバリが開発中- Azure Stackの構成が勝手に変更されてしまっていないかを検出、修正する機能が開発中- Azure Stackの構成が「規定で堅牢化」されていることを確認できる機能を開発中- Azure Container Service(AKS) on Azure Stack開発中- サービスファブリッククラスターのテンプレート展開開発中。- Azure Stack上でのWindowsおよびLinux仮想マシンでのサービスファブリックのサポート。GA。- Azure Site RecoveryでのAzure Stackサポート 開発中。Azure Stack to Azureの方向に(説明文章が)読めます。- Azure Stackインフラのバックアップとクラウドリカバリ開発中。マニュアル操作を省いたものに改善されるようです。- Azure Stackでのマネージドディスク開発中。- Av2シリーズとFシリーズの仮想マシンサイズ。開発中。- VPNゲートウェイのよりフレキシブルな設定。開発中。- Azure Storage APIバージョン2017-0417のサポート。開発中。- Azure Stackへのノード追加。開発中。- Azure Stackの複数スケールユニットのサポート。開発中。- Azure Stackオペレーターへの機能アップデート。開発中。モニタリング、診断、サービス提供周り。- Azure StackインフラのPCI-DSS, CSA-CCMコンプライアンス認証に関しての説明ドキュメント。開発中。- Azure Stackポータルでの仮想マシン料金の表示。開発中。- Azure Stack上でのWindows, Linuxのコンテナのサポート。GA。- Azure StackへのKubernetesクラスタのテンプレート展開。開発中。 Azure Container Service(AKS)がいいですね!

February 13, 2018 · 1 min · 胡田昌彦

「ハイブリッドクラウド研究会」にコミットして活動していきます

Microsoftの(元)エバンジェリストの高添さんから下記のブログが公開されています。 - *[2/20 ハイブリッドクラウド研究会がスタート! ~日本中をなんちゃってハイブリッドクラウドから卒業させよう~ – 高添はここにいます](https://blogs.technet.microsoft.com/osamut/2018/02/07/hybridcloudcommunitystart/)* 中には「一緒にやりたいという思いを語ってくれたJBS胡田さんにもご協力を仰ぎ」ということで私にも言及頂いています。 私自身も過去のこのブログのエントリの中で 大きく言えば日本のエンタープライズのIT環境に革新を起こしたくおもっており、その中心になりたいと思っています。Azure Stackにはそれができる可能性が大いにあると思っています。 と、書きました。自社の社長からも「自社のためだけじゃなく、業界全体のために活動しろ」と言われています。この「ハイブリッドクラウド研究会」はその具体的な1つの場所になると思っていますし、そうしたいなと思っています。 創立記念&参加企業募集イベント の申し込みは以下ですので、興味ある企業様は参加いただければと思います。 - [「ハイブリッドクラウド研究会」創立記念イベント - connpass](https://hybridcloud.connpass.com/event/74887/)

February 7, 2018 · 1 min · 胡田昌彦

Offcie 365 ProPlusがサポートするWindows(更新し続けないものはサポートしない)

Office 365 ProPlusがサポートするWindowsのバージョン周りのアナウンスがブログで出ましたね。 To clarify our current support practices for ProPlus running on Windows 10, ProPlus will not be supported on Windows 10 Semi-Annual Channel (SAC) versions that are no longer being serviced. Effective January 14, 2020, ProPlus will no longer be supported on the following versions of Windows. This will ensure that both Office and Windows receive regular, coordinated updates to provide the most secure environment with the latest capabilities. Any Windows 10 LTSC release Windows Server 2016 and older Windows 8.Source: Changes to Office and Windows servicing and support – Windows for IT Pros 要は、Microsoftの考え方をよりはっきりさせるためにサポートポリシーを変更します、ということで ...

February 5, 2018 · 1 min · 胡田昌彦

超おすすめ本「The DevOps 逆転だ!究極の継続的デリバリ」

以前もどこかで紹介したことがある気がしますがこのブログには書いていなかったようなので、超良書を紹介します。 The DevOps 逆転だ!究極の継続的デリバリこの本はタイトルにもある通りDevOpsとは何かから始まって、そもそも何を解決するのか、ツール、サービスの紹介含めて具体的な方法論を詳しく説明する……………のでは全くありません(笑 私の記憶ではDevOpsという単語すら出てこなかったと思いますし、ツールやサービスなんて全くでてきません。技術的な要素はほぼないといっても過言ではないかもしれません。 でも、それにもかかわらずDevOpsの本質をよく理解できますし「(DevOpsのようなアプローチが)なぜ必要なのか、何を目的として何をすべきなのか」が物語形式できちんと理解できるが内容になっています。 「ITはビジネスに貢献しなくてはいけないんです。それはクラウドによって実現できます!昔ながらのやり方はやめてITの新しい使い方を始めましょう!」というのはコメントの内容としてはすごく正しいんですけど腑に落ちないと思うんですよね。そこに対してこの本には「物語の力」があります。 多くの情報システム部門の方が「あるある」と頷ける日々の苦労、努力がきちんと描かれ、そこから地続きでITのあるべき姿まで描かれます。なので、本の大部分は当事者は胃を痛くしながら読むことになるとなると思いますが、業界全体の目指している、進化している方向がよくわかると思います。 というわけで、本当におすすめです。情報システム部門の方、SIerに努めるかたはもちろん、事業部門の方や経営者にもぜひ読んでもらいたい本になってます。 私自身はこの本をMicrosoftのJeffrey Snover氏がおすすめしていたので読みました。読んでよかったです。皆さんもぜひ。 The DevOps 逆転だ!究極の継続的デリバリ

February 3, 2018 · 1 min · 胡田昌彦

Azure Stack用に証明書を用意する

今回はAzure Stack用に証明書を用意する際のポイントに関して備忘録を兼ねて書いておきます。自社導入時に少々整理する必要がある点もあり、まだあまりまとまった資料もありませんでしたので…。 と思って書き出そうとしたら公式サイトに1月30日にドキュメント追加されてますね!良いことです。 Azure Stack Public Key Infrastructure certificate requirements for Azure Stack integrated systems | Microsoft Docs- Generate Azure Stack Public Key Infrastructure certificates for Azure Stack integrated systems deployment | Microsoft Docs 自分が書こうとおもっていた注意点はここにまとめられていたので…特に書くことがなくなってしまったのですが、ハマりどころだけ書いておきたいと思います。 後からサービスを追加すると追加で証明書が必要になる形態で作られているので、「Azure Stack用の証明書用の予算」は多めに確保しておくのが吉です。組織内のCAからの発行であればそこは気にしなくてよいのですが。ただ、現実的には公的証明局の証明書での運用は難しそうです。(The ACS certificate requires three wildcard SANs on a single certificate. Multiple wildcard SANs on a single certificate might not be supported by all Public Certificate Authorities.)- ドキュメントにある通り、iniファイルを書いて、Windows標準のcertreq.exeで証明書要求を作成するのが1番簡単だと思います。(私がWindowsに慣れているからそう思うだけかもしれませんが)- Windows ServerのCAを利用するには、規定では有効になっていないSANを有効化する必要があります。有効化する方法は下記参照。- セキュリティで保護された LDAP 証明書にサブジェクトの別名を追加する方法- ハッシュアルゴリズムにSHA1は使えないので、必要に応じてcertutilにてCAのハッシュアルゴリズムを変更する必要がある。- 暗号化サービス プロバイダー (CSP) からキー記憶域プロバイダー (KSP) への証明書機関キーの移行

January 31, 2018 · 1 min · 胡田昌彦