Office 365 管理者アカウント 強制MFA機能(Baseline security policy)と対処法
最近がんばってるAzureADチームがナイスな新機能をリリースしてくれました。
- 全体管理者
- SharePoint 管理者
- Exchange 管理者
- 条件付きアクセス管理者
- セキュリティ管理者
上記権限を保有し、かつMFAが有効になっていないアカウントについて、強制的にMFAが有効になります。これらのアカウントをスクリプトで使用していたり、共用で使用している場合は、運用上支障が出ます。
対処法
その1. 機能を無効化する
この機能はプレビューであり、GAされた段階で強制MFAが発動します。それを防ぐためには以下画面で「ポリシーを使用しない」を選択します。
その2. MFAを有効にしないアカウントを選ぶ
MFAを使わないアカウントが整理できている場合、同じ画面から除外対象アカウントを指定できるので、MFAを有効にしないアカウントを指定します。
なお、他の選択肢として「全ての管理者アカウントでMFA有効化」がありますが、この設定を使用すると後述の通りスクリプトでの管理タスク実行に支障が出るため、現実的には「MFAを除外するアカウント指定」を使用するべきでしょう。MSも「全てのアカウントについてMFAを利用するのではなく、緊急用の管理者アカウントを1つはMFAをオフにする方法」を提示しています。
Manage emergency-access administrative accounts in Azure AD | Microsoft Docs
さらっとしか流し読みしてませんが、パスワード文字列を2つか3つに分けて、別々の人間が知るようにする、などが書かれています。
SIer的な立場として
こんなうざったい機能がリリースされたからオフにしちゃいましょうはアウトな気がします。今までは規定値がMFAオフだったので許されていたかもしれませんが、今後は規定値がオンなのをオフにするので…。
- SIerが明示的にMFAオフにする
- 結果、アカウントが乗っ取られる
- SIerが悪いんじゃね?
という話になりそうな気がします。最低限、説明責任を果たして、顧客の同意を取ってからオフにするべきでしょう。
推奨設定
といってもスクリプトで管理者アカウント使いたい！という人向けに推奨設定が出ていました。
対話的に使用する管理者アカウント
人間が非定形作業で使用するアカウントは(ちょっと面倒ですが)二要素認証を有効にします。Exchange Onlineの場合はこんな感じ
多要素認証を使用して Exchange Online PowerShell に接続する | Microsoft Docs
「俺はSecurePasswordでパスワードを暗号化してるんだ！」「パスワードも十分強力にしてるんだ！」「だから二要素認証なんて要らなんだ！」という方はご自由にどうぞ。
タスクスケジューラーなどで動かす管理者アカウント
夜間バッチなどに埋め込んでいるアカウントはMFAが使えません。つーかMFAオンにしているとバッチが動きません。なので仕方なくMFAをオフにするのですが、その場合は以下のように注意をしてください、とのこと。
- RDPを禁止する
- クラウドIDなら問題ないですね
- 管理者作業に用途を限定し、メールなどは有効化しないようにする
- 着信したマルウェアをクリックしちゃうと大変ですからね
- 居力なパスワードをセットする
- アカウントに対する監査ログを有効化し、定期的にチェックする
- 社内IPからのアクセスに限定する
- 管理役割を厳密に設計し、不要なコマンドレットの実行権限を外す
- これはさすがにめんどくさい…。
将来的に
タスクスケジューラーで動かす管理者アカウントもセキュアに守りたいやん、ということで、Azure MSI(Managed Service Identity)という仕組みが勧められています。
What is Managed Service Identity (MSI) for Azure resources | Microsoft Docs
しかしながら現在はAzureの一部コマンドしか対応しておらず、Office 365的には使えないものになっています。なお私はAzure MSIの仕組みを詳しく理解していません。使わなきゃな。
余談：GraphAPI
同僚とこの件に会話していて「もしかしてGraphAPIで適切にアクセス権を振れば、MFA回避できるんじゃね?」という話題が出たので試しました。結果、GraphAPIでもMFAが効いたことをお知らせいたします(当然ですね)。一点注意として、強制MFA有効化前にトークンを取得していれば、継続してアクセスが可能であり、トークンの有効期限が切れた時点でMFAを求められ、スクリプトでのアクセスが不可になります。時限爆弾。
余談：MFAの実装方法とGA時期予想
KBの注意書きに、MFAが有効になった管理者アカウントは、POP/SMTP/レガシーのOutlookクライアントからもアクセスがブロックされるよと書かれていました。これは検証していないですが、この注意書きが正しいとすると、最近Azure AD Premiumのプレビュー機能として実装されたレガシーブロックの機能を利用していると考えられます(旧MFAはレガシーブロックできなかった…はず)。ということは、Azure AD Premiumのレガシーブロック機能がGAされるまで、Baseline security policyも有効にならないのかな?と思いました。
Azure AD スマートロックアウトのカスタマイズ機能について
こんなリリース(プレビュー)がありました。
機能としては3つで
- ロックアウト閾値の変更
- 禁止パスワードの定義
- オンプレADのパスワード保護
となります。1と2は以前からGraphAPI経由で変更できた機能です。
3は新しくリリースされました。
1. ロックアウト閾値の変更
Azure ADのロックアウト値は規定で
- 10回連続でパスワードを間違えた場合
- 60秒間ロックアウトがかかる
です。この値を変更できます。
この機能の何がうれしいの?ということですが…。
例えば、社内のセキュリティ部門が定めているポリシーでパスワードは3回連続間違えたら1時間ロックアウトすべし！と決まっていて、Azure ADが導入できない場合など。あるいは、外部からアタックされてもアカウントが即ロックしないように、100回連続でパスワードを間違えてもOKにしたい、など。前者はセキュリティ重視、後者は利便性重視ですね。
余談
MSとしてはAzure ADで提供している
- ブラックリストIP
- IPロックアウト
- スマートロックアウト
の3つの機能で、利益目的の攻撃者のアタックをほぼ防げる、と主張しています。1はそもそも怪しい所からのアクセスは禁止する、2はパスワードスプレー攻撃への対応、3はブルートフォース攻撃への対応です。そこらへんのロジックはMS本社のSIMONSさんの神エントリをご覧ください。
てことで、利便性重視の設定にしてしまって問題ないと思われます。
具体的には、NISTのガイドラインに従って、ロックアウト回数を100回にするのがよいです…ってMS日本のセキュリティの方が言ってました。
なお、上で提示したリンク(Azure AD Connect: Pass-through Authentication - Smart Lockout | Microsoft Docs)に、
- The Azure AD lockout threshold is less than the Active Directory account lockout threshold. Set the values so that the Active Directory account lockout threshold is at least two or three times longer than the Azure AD lockout threshold.
- The Azure AD lockout duration (represented in seconds) is longer than the Active Directory reset account lockout counter after duration (represented in minutes).
とあるんですが、パスハードハッシュ同期でAzure ADで認証している場合、この記載は無視してもらって大丈夫、のはずです。パススルー同期でオンプレADを認証基盤としている場合、外部からのアタックによってオンプレADのアカウントがロックアウトしてしまうので、上記のような施策でAzure AD 側を先にロックアウトさせ、オンプレADを継続できるようにする施策のようです。
…とはいえ、パススルー認証で外部からアタック受けた場合、Azure ADのパスワードロック閾値が動作するのか?てのは疑問です。パススルー認証導入したことないから分からんけど。
2. ロックアウト閾値の変更
これは単純で、登録した単語を含むパスワードの設定を禁止できる機能です。面白い所は、「よく置き換えられる文字を自動的に禁止する」こと。例えば
- password
という単語を登録した場合
- p@ssword
- passw0rd
- p@ssw0rd
- p@$$w0rd
などなども、同時に禁止されるようです。
3. オンプレADのパスワード保護
オンプレADに、Azure AD password protection proxyってのをインストールする事で、オンプレADでAzure ADで禁止されているパスワードを使っているユーザーをあぶりだす事が出来るお楽しみ機能です。例えAADCでパスワード同期をしても、Ctrl+ Alt + DeleteでオンプレADに対してパスワード変更をすればAzure ADのパスワードポリシーは無視されるので、P@ssw0rdのような脆弱パスワードがインターネットにさらされることになり危険ですので、有効にしたほうがよい気がします。
この機能を有効にする際に"強制"と"監査"が設定でき、"監査"だと弱いパスワード設定しているユーザー一覧が出力され、"強制"で設定を強制できるようです。"強制"時の挙動は書かれてませんが、次回パスワード変更時までは今のパスワードが使えるのかな?
何にせよ、この機会に脆弱なパスワードを使っている意識低いユーザーを洗い出して、要注意ユーザーリストを作ってセキュリティ教育を強制させるとかの使い方も面白いかもしれません(どこか導入させてくれ～)
必要なライセンス
- ブログ主のSIMONSさんは"全てのAzure ADで使える"と言っている
- 日本のMSに確認した所、v2が必要です、と言われた
- E1テナントだと設定自体が出来なかった
- P1テナントだと設定が可能である
と、現状ではどのライセンスが必要なのかはっきりしません。システムがせいだとするなら、少なくともAADP1以上は必要のようです。
GraphAPIの時も"AADP1で設定は出来るけど、AADP2しか使っちゃいけない機能だから、設定するとライセンス違反"という罠があったので、MSから公式アナウンスが出るまでは触らない方がよさそうです。
2018/6/22 追記
ブログ更新されてました。
- 全てのAzureADで使用可能
- Custom smart lockout
- P1以上が必要
- Custom banned passwords
- Password protection for Windows Server Active Directory
だそうです。
第22回 Office 365 勉強会
第22回だ！
第22回 Office 365 勉強会 - connpass
2018/6/16(土) 13:00-18:00。参加者は80名くらい(?)でした。以下、セッションとその他感想です。細かい感想は上記リンク先のtogatterまとめを見ればよい気がするので、このエントリでは私が単純に思ったことを書きます。
Office 365 ProPlus の 更新管理 と SCCM
「自宅ラック友の会」というパワーワードを引っ提げて、オンプレ・クライアントのカテゴリ感が強い、ProPlusとSCCMの話。O365利用のためには最新版のOfficeが必要で、事実上ProPlusの更新管理をする必要がある。SACのアップデートについていく必要があり、企業ユーザーには難関である。SCCM使えばそこは管理できる。
私は、SCCMないお客さんでIISServer + Office 展開ツール(ODT)で作れるconfig.xml使ってProPlusの更新運用を設計したことがあり、ひとまずそれはうまく回っている様子です。SCCMの事はよー分からん。しかしながらWin10デリバリチームに聞くと、Win10の管理にはSCCM必須やし結局2020年になればみんなWin10になるから勉強するしかないっすよ(しろよ)、との事らしい。
確かにお客さんの中にはWin10の運用上手く回してて、拠点にハブマシン作ってUpdate配布(※)とかやってる会社もあり、大規模環境 & 拠点数がたくさんあるなら、SCCM絡めたWin10 + Office ProPlusの更新管理をする必要があるんだろうな、って。
(※ Win10のWindowsUpdateには、拠点の代表クライアントPC1台に更新プログラムを配置して、LAN内の他のマシンはそのマシンにUpdateを取に行かせることでWAN回線を節約する機能がある。詳しくはde:code18のWin10更新管理のセッション参照)
欠点としては、このフローに乗らないソフトウェアもあって。例えばTeamsはOffice ProPlus製品じゃないからクライアントPCが個別にインターネットに更新プログラム取りに行って死ぬ、など。
MSさん内部でWin10チーム、Officeチーム、Teamsチームが離れててソフトウェア更新フローが統合されてないのかな?と勘繰っちゃいますが、Office 365 / Microsoft 365入れるお客さんは製品群をトータルで管理できる事を期待しているしSIerとしても期待しているので、MSさん推奨のSCCM構成組むから、全部そのフローに乗せて更新できるようにしてよ、とは言いたいです。
SIer視点だと、365の躍進でクラウドベースのエンジニアが重宝され、枯れた技術として軽視(?)されてきたオンプレAD・PCクライアント管理人が、逆にクラウドの方が枯れてきて今後は主役になりそうな気がするんですよね。その時にクラウドベースのエンジニアとオンプレエンジニアが協力してM365環境に一気通貫で対応出来れば、他社に比べて相当アドバンテージになりそうな気がするんだけどな。特にFlowがWin10のアクションを拾えるようになったりしたら、RPAもM365で作れるようになるかもだし、ハッカソン開いてM365で遊び倒すのも面白いかもしれない。
まずは最低限の要件としてWin10/O365のSACに乗れるレベルの更新運用勝ちパターンを構築する事でしょうか。それが出来ればお客さんもうれしい、ベンダーも(ビジネス的に)うれしい、1社のベストプラクティスが他社にも転用できるかも?なOffice 365 黄金郷が見えてくる気がします。
などなど。
Office 展開ツール(ODT)がGUIで作れるようになった、ってのがありがたい情報でした。
Office Deployment Scripts for IT Pros by OfficeDev
Office 365 を楽しもう！（家庭で Office 365 を使ってみたところから業務での利活用促進を考える）
アイディアがめっちゃ面白かったです！365の製品知っててアイディアがあれば、こんないろいろ出来るんだなって。Plannerを家族で共有、SharePoint Onlineはモバイルからたどり着き辛いから、ガワをPowerAppsで作るってアイディアが面白かったです。あとは目立たないけど失敗事例も。非ITの人に新しくアカウントを作ってもらったり、普段のソフトウェアを変更してもらうのは難しい。
Plannerの機能単体だと、TodolistやasanaなどのPJ管理ツールでもいいんだけど、他のサービスも使って、それらのサービスと1つのアカウントでSSO出来るって利便性が非ITの人向けにはいいなって思いました。エンジニアならTodo管理はasana、メモはgoogle keep…など、用途によって一番最適なツールを選ぶことが出来るけど、そうじゃない人には苦痛なだけなので。一通りなんでもそろってる365の強みかなと。
LT
助成金の話が面白かったです。正直、全然知らなかったので、こういう視点の発表もあるんだって驚きました。あ、あと自分も発表しました。終わった後でtwitter見ると好意的な反応が多くてうれしかったです。僕はSharePoint初心者なので、慣れているExchange Onlineを選びました。今となっては枯れたシステムですが、企業で一番利用されているOffice 365機能ってExchange Onlineじゃね?と思っているので、これからもネタがあれば発信します。
セキュアに使おう Microsoft Teams
これは圧巻でした。こういうストーリーを持ってお客さんに話せるとコロっといっちゃうのかな、と思いました。自分の話をすると、EM+S案件には2年前くらいから関わって、それ系のイベントも行っているのですが、イベントでEM+Sの機能が押されることはなく、まさに啓蒙活動が中心なイメージ。外部からの攻撃に対する製品だから当然なんですけど、セキュリティリスクはこんなんですよ、発生したら某社みたいになっちゃいましょ、みたいな。
セキュリティ施策ってどうしても"前例主義"で見直しが少ない、まさに「Teamsを危険と言いつつメールの添付ファイルな野放しな状況」が各社なのです。で、情シス担当者としては波風立てたくないし、上の人も危険性が分かっている人は少ない。
なので、EM+Sに関わらずセキュリティ製品を売る人は、そういった目に見えない危険性とかリスクをストーリー立ててしっかり説明する必要があるんだなぁ～とエンジニアの私は眺めてました。お仕事取ってきてくれてありがとうございます。
EM+Sに関しては、AIPとか条件付きアクセスがシナリオ通りにいかない所もあるんですけども。
おとなのたしなみ Microsoft Flow
Bot Service使ってPowerAppsに通知送るとかIFTTTと連携してGPS自動連動とか、Flowは知識増やしでアイディア練れば面白いネタがいくらでも埋まってそう。特に自分はPowerApps、Bot Serviceは全然わかっていないので、ちゃんと触って何が出来るか理解したい。特にPowerAppsは最近アツい。これを触ればOffice 365 のサービスは一通り触った事になるのかな?と思うので早めに取り組もう。
※ StuffHub?何それ?
まとめ
そんな感じで今回も非常に面白かったです。主催者のもくだいさん、お菓子係のみなさま、ありがとうございました。次回もぜひ参加できればと思います。
Monthly Office 365 Update (2018年3月分,4月分,5月分)
Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。マンスリーなのに3か月分を一気に更新。
チェックソース
- メインソース
- サブソース
- Office 365 Roadmap | Microsoft
- TechPlus ライブラリ
- その他各種ブログ情報
その前に。前回の更新のおさらい
MC128924 See Microsoft Planner tasks in iCalendar
こちら、リリースされました。予想通り、iCalをインターネットに公開する方式なので、情報漏れます。
Monthly Office 365 Update (2018年1月分,2月分) - 今日も元気にIT屋さん
しかしながらiCalに乗ってくる情報は…
- 件名→連携される(漏れる)
- 日付情報→連携される(漏れる)
- チェックリスト→タスク総数と完了数だけ連携される
だけで、肝心の内容部分である… - 説明欄→連携されない - 添付ファイル→連携されない - コメント→連携されない
は大丈夫。漏れるのはタスクの件名欄のみ。あんまり大騒ぎしなくていいかも。 予定表は、タスクの件名と日付の情報だけicsファイルに含まれ、本文にはPlannerへのリンクが表示される。 Exchange Onlineでいう「件名だけ公開」と同じような形です
またicsファイルの公開アドレスは簡単に推測できるものではないです。
https://tasks.office.com/[O365テナントID]/Calendar/Plan/[プラン名?グループ名?]?t=[乱数?_発行日付(ミリ秒単位?)]
外部のユーザーが総当たりで公開されているプランのカレンダーにアクセス成功する確率は低いです。
てことで、神経質にならなくてもいいかもですが、気持ち悪い場合、以下の手順でPlannerの共有をOFFにします。
組織のプランナーで Outlook 予定表の同期をオフにします。 - Office サポート
Office 365 メッセージセンター
MC133135 Office 365 Groups created from Microsoft Teams will be hidden from Outlook by default
Teamsでチームを作ると、それに紐づいで作成されるO365 GroupsがOutlook左ペインに自動的に追加される仕様だったが、表示されなくなる。Teamsをヘビーに使っている場合、いつの間にかTeamsとしてしか使っていないO365グループが左ペインにぽこぽこ追加されているためウザい。この判断はOKだと思います。
MC133236 We’re making changes to Office 365 IP Address range and URL publication
2018年10月2日に、従来のRSSでのOffice 365 IP アドレスと URLの配信が中止され、RESTベースのXML or csvでの配信になります。こちら、インフラエンジニア的にはそこそこ大きい変更でありまして…
- 自作スクリプトでOffice 365 IP アドレスと URLを取得している場合、スクリプトの改修が必要
- ネットワーク機器自身がOffice 365 IP アドレスと URLを更新するサービスを販売している事業者は、サービス継続のためにネットワーク機器に仕込んでいる仕組みの変更が必要
となります。たいへんたいへん。
しかしながら、従来のOffice 365 IP アドレスと URLでは、そのURLがExpress Routeを通るか通らないかの情報が取れませんでした。
MSがOffice 365に関わるPACファイルを作成してくれる件 - 今日も元気にIT屋さん
今回の変更で、Express Routeの有無も含む情報が取れるようになったので、まさに望んでいた情報が手に入ることとなります。FlowやLogicAppsでRESTの解析もできるからプログラム書く必要もないし、よい変更だと思います。
MC133271 Microsoft To-Do Steps
MC140111 Microsoft To-Do List Sharing
Microsoft To-Doでサブタスクを追加できたり、他人とTo-Doの共有ができるようになりました。最初のリリースの時に触って失望して、今はasanaでタスク管理しているのですが、ずっとTo-Doを使っている人が「そこそこ使えますよ」とか言っているので、勉強のために使ってみようかなと思うこの頃です。
MC134487 Groups in Outlook and Group-connected team sites are now private-by-default
Outlookなどで作成したO365 グループは、強制的にグループに紐づいたSharepointサイトができるのですが、その規定値が非公開になりますよ、という話。
MC136565 Updated: Microsoft Teams trial for commercial cloud customers
とある条件を満たしたテナントでは、Teamsのトライアルが使用できるようになり、ユーザー自身の意思でTeamsを使用開始できる、という話…っておい。この機能は対象のテナントにプレゼントされて規定で有効になるため、嫌ならOFFにしてね、とのことです。
Manage the Microsoft Teams Commercial Cloud Trial offer | Microsoft Docs
僕のテナントでは既にTeamsを使っているため対象のテナントではないのですが、これ、意識的にTeamsを使わせてないテナントとかで有効になってたら大変じゃないの?ちょっと動作確認が取れないので、どんなものかわからないのですが…。
MC136899 Updated feature: Email quarantine capabilities
Exchange Onlineの検疫管理(スパムマルウェアとして検知されたメールを隔離し、管理者が再配信できる管理画面)が、2018年10月に現在のExchange Online管理センターからセキュリティ&コンプライアンスセンターに代わるらしいです。機能も強化され、保管機能が増えたり選べるアクションが増えたりする様子。
MC137650 Updated feature: Group followers will no longer receive all Planner task email
今まで、O365グループに紐づいたPlannerのタスクに誰かがコメントしたら都度O365グループにメールが飛んで、O365グループの受信トレイをフォローしているユーザーにびしばしメールが飛んでいたのが、変更後は、自分が関係ないタスクのメールは、変わらずO365グループに飛ぶんだけど、関係ないユーザーには転送されない、という仕組みらしいです。
O365グループに着信したメールは問答無用で転送される仕様だと思ってたのですが、こんなコントロールもできるんですね…?翻訳間違ってるのかな。もし本当ならいい変更だと思います。
MC137770 Redesigned Message Trace in the Security & Compliance Center
検疫機能がセキュリティ&コンプライアンスセンターに代わるのと同じで、メッセージの検索も代わっていくようです。
MC139542 We are updating the details of Service Health Communications
O365管理センターのサービスの状態で、障害によって影響を受けているユーザー数が見れたのですが…。これが5月30日に廃止されるようです。なんてこったい。また、以前(2016年くらい)に、O365の管理センターが新しくなって、指定したユーザーのステータスが見れるようになるぜ！って言われてたのですが、リリースがキャンセルされたようです。(Office 365 ロードマップ キャンセル済み Feature ID: 15064 を参照)
原文ブログ(削除済み)
日本語訳ブログ Office 365 管理機能更新のお知らせ: 新しい管理センターの一般提供開始とサービス正常性ダッシュボードについて – Office Blogs Office 365 管理機能更新のお知らせ: 新しい管理センターの一般提供開始とサービス正常性ダッシュボードについて – Office Blogs
その他ブログ情報
Outlook for iOSの新しい機能のリリース予告
セキュリティ関係では
- プロキシを設定できるようになった
- 1つのO365アカウントにしか接続できないようになった
1について。WindowsPCではプロキシを踏ませて指定したサイト以外へのアクセスを遮断する、というのがセオリー。Outlook for iOSは、例えばOutlook for iOSから個人のGmailアカウントに対してのアクセスをブロックする、という使い方ができる。
2についてはそのままの意味で、「O365」というアカウント種別を1つしか設定できなくなるので、個人のO365アカウントへの接続を禁止することができる。
ただ、どちらも社外への情報漏えいを防ぐための機能だが、Intune配下のiOS/Androidなら元々(情報漏えいを防ぐことは)できていたことなので、今更Outlook for iOSに実装するメリットはないかも?
#decode18 に参加した感想
割と浅めの感想です。
2018/5/23(水),24(木)にマイクロソフト社のイベント「de:code」に参加しました。 米国Microsoft本社では
- Build
- Inspire
- Ignite
ってイベントをやってて、それぞれが開発系・営業系・インフラ系のカテゴリとなります。今回の「de:code」は先日のBuildを受けた上での開発系エンジニアのためのイベントなので、インフラ系の私は適任ではない気がしたのですが…ってことで浅い感想です(予防線)
day1
DA03 スマート シティにおける AI カメラの活用例 ～街の人・モノをカウント～
日本システムウェアさんのCityVisionのご紹介。機械学習はクローズアップされているが欠点として
- Deep Learning分かる人少ない
- データ前処理の手間と時間
- 学習コストヤバイ
というのがあります。タイムリーにこの前のrebuild.fmでもそんな話してました。
Rebuild: 208: Oculus Go On The Go (higepon)
その欠点を解消したのがCityVision。特徴として、裏側でAzureMLを利用しつつ、人と車を数えることだけに焦点を置いたものである。こちらですね。
NSWの画像AIを活用した人・モノカウントサービス、 日本マイクロソフト主催イベントde：code 2018に画像分析ソリューションとして提供 | 日本システムウエア株式会社
つまり、「人」と「車」のモデルがあらかじめ定義され済のものを提供してくれる、ということ。初期費用10万円、サービス継続料は月に2万円ということで、交通量調査する人を安いよりも安価でしょ、と。
人の待ち行列を数えたいときって結構あります。例えばdocomoショップの並びとか、ラーメン二郎の並びとか、ゲレンデのキッカー待ち人数とか。こういったものがインターネットから確認できるようになれば、利用者としてはいろいろ便利だな～。とはいえ、サービス提供側が、なんで行列を他人に公開せなあかんねん、という課題はあるので、実際の売り込み先は考えないといけないぽい。
AD10 Azure PaaSとOffice365で基幹システムを拡張 ～ERPのAPI化とノンコーディングモバイルアプリ開発 ～
レガシーの代表であるSAPを、今流行りのWeb化やモバイル化をどうやって進めるのか。SAPの中をカスタマイズしたりSAP用の3rdパーティー製アドオンもあるらしいが、品質やサービス継続性が不安だったりするので(それを言うならO365の周りで商売している3rdパーティーもそうだが…)
- SAPはそのまま使う。その周りの周辺システムを整備する
という「Bolt Onの考え方」でやりましょう。
レガシー的なBolt Onの考え方でやると
- アウトプットデータをExcelで見るので、ローカルのセットアップが必要
- 各PCにセットアップしたツールの変更管理が大変
- オンプレミスの中に閉じるのでスマホ対応できない
という課題があるので
- On-Premise Data Gatewayでデータに外からアクセスできるようにして
- Logic Appsでデータを使う
のストーリー。この流れでさらに
- 作成したLogic AppsをAPI化し、Azure API Managementに登録。
- Azure API ManagementでAPI管理が可能。
です。単一アプリなら3.4.をやらなくていいけど、業務アプリのデータを全社が使えるようにするなら必要かな。PowerAppsでAPI Managementで管理するAPIを参照出来る様子。
SAP経済圏の中でもスマホアプリ見れるソリューションとかありそうだから、世界を見渡した時にベストプラクティスかはわからないけど、MSワールドでやるならこの方法がクールだな、と思いました。
※ けど後で弊社のSAP担当に聞いたら、Concur(SAP経済圏のアプリ)でデータを引っ張らないとちゃんと取れない、という話もあり、On-Premise Data Gateway大丈夫かな…と
AD07 戦う情シス！全社 API で社内アプリ開発を加速させよう
花王さんの社内情シスの話。雰囲気、ばりばり社内で業務アプリケーション開発してそうでした。
人事情報を取るためにAzureADにアクセスするAPIを作って開放。csvで定期的にデータをエクスポートして渡すより、データは中に持ったまま都度渡す方がセキュアでよい。
- API Management
- Application Gateway
- WAF
- SSLオフロード、セッションアフィニティ
を使って制御。WebAppsが基盤なので、いろんな設定が簡単にできる。認証が簡単に選べる
難点として、社内のシステムはL4な考え方だが、PaaS,FaaSはL7なので、それをつなげるのが難しかった。
- L7のサービス：固定IPが持てない
L4のサービス：固定IPが持てる
App ServiceをVNetに入れる
- API Management をHTTPSのプロキシとして使う
- VNet 統合でL4リソースにアクセス(Point to Site VPN)
社内資産であるL4とPaaSの最適解であるL7の統合が課題。
ちょっと私の業務内容とは全然違う話だったのでメモしてるポイントも違うかもですが、API Managementって自社WebサービスをAPI化して3rdパーティーに開放するときに使うイメージだったので、社内コントロール向けに開放するって考えが新鮮でした。
SP08 エバンジェリスト恒例スペシャル対談 ブロックチェーン／仮想通貨スペシャルトーク～今すぐ始めようビットコイン～
アイドルグループである仮想通貨少女、bitFlyerの社長さん、MS西脇さんの異色のセッション。仮想通貨少女が高校生のアイドルグループなのにブロックチェーンやハードフォークといったIT用語を説明してるのが面白かったです。会場では、ビットコインを買ったことがない人がほどんどで(登壇者も驚いていたが)、ブロックチェーンの仕組みの紹介からビットコインを実際に買ってみるとか、個人間送信してみるとか、割と基礎的な内容が多くて新たな知見は少なかったかな。
仮想通貨で個人間送金出来るとはいえ、LINE PAYもできるし、中国発のアリペイなども強い。ここらへんは、どの通貨が天下を取るのかの戦いだと思います。
日本ではいろんな意味で悪目立ちしてしまった仮想通貨ですが、裏側のブロックチェーン技術は本物。エンジニアがビジネスをリードできるインターネット以来の発明、しかもそれを日本がリードしている、このチャンスを逃さない手はないってbitFlyerの社長さんの発言が印象に残りました。
day2
AD12 コーディングレスなアプリ開発 -業務アプリを1時間で- [AD46 と同一内容]
業務部門のためのアプリを情シスがスクラッチから作ってると遅すぎるので、マイクロソフト社がテンプレから作れるPowerAppsを用意したよ。PowerBI / PowerApps / Microsoft Flowの3つを合わせてビジネスアプリケーションプラットフォームとか呼ぶよ。今回は45分くらいで
- スマートフォンからの電車賃生産
- GPSで自分の位置を取得
- 出発地と目的地の駅を入力すると、裏側で電車料金計算
- 写真で画像取り込み
- OCRで画像の文字分析
をやります以下デモ。デモの量がすさまじく、ほんとに45分でアプリが作れました。これは"慣れれば"の話なので、初学者はトライアンドエラーしないといけないですが、慣れれば例えばモックをPowerAppsで作って業者に見せて発注する、とかもできるかもしれないです。
ググると、民生用でもノンコーディングでスマホアプリ作れるサービスがあるらしく。個人でもこういった世界が利用できるとなると、仲間内のためにiOSアプリ作ったりもできそうですね。
- プログラミングの必要なし！簡単にスマホアプリが開発できるツール9選
- プログラミング不要！簡単スマホアプリ開発ツール11選！ | 構築ツールの最新情報や基礎知識 | 知る・学ぶ | Marketing Bank （マーケティングバンク）
- コーディング知識ゼロでiOS/Androidアプリが作れちゃうサービス×13選 - ニフクラ mobile backend（mBaaS）お役立ちブログ
- ノンプログラマーでもアプリ開発ができる！無料のアプリ開発ツール5選
ただ、価格が高い…。自分が作って数人の友達に配布するレベルではこの金額は出せないですね。
- Pricing | Appery.io 720$/年
- Mobile App Pricing | Bizness Apps 1188$/年
- AppMakr :: Pricing :: Choose an option and publish your own app. 1188$/年
- Pricing - Affordable native app development - Scalable pricing 336$/年
- Yapp - Pricing 399$/年
AD02 Serverless の世界を進化させるイノベーション - Durable Functions
最初のセッションの後、Ask the speakerでいろいろと(AD12とその他別件)話していたので遅れて入室。大して聞けず。
AD63 Logic Apps でコードレスに作る ChatBot
LINEbotで写真が送られたらアクションするbotを作成。Logic AppsではLINEのメッセージを受けるように設計。LINEのメッセージ形式が分からなくてもエミュレート(?)する機能があり、楽に実装できるとのことでした。あと、bot系を作るならWebhook有りのLogic Appsで使わないと課金的に死ぬ、という話。
CI24 Microsoft 365 と Microsoft Azure で実現するサーバーレス業務アプリケーション
ソフトバンクテクノロジー社のセッション。Microsoft 365 を基盤として動作するSBT Flowと、Microsoft 365の紹介。Microsoft 365を基盤としているので、AzureADPの条件付きアクセスや権限コントロール機能を使う、IRMを利用して文章保護など、通常のワークフロー機能に加えてAzureADPの強力なガバナンス強化機能を使える。AADPの技術は理解しているからいいとして、SBT Flowってのが、他のワークフロー製品と比べてどの程度優位性があるのかが知りたいな～と思いました。
AC13 クラウドでここまでデキる Ver.1805 ～今こそ Windows 10 をモダンに管理する
Windows10展開時のAutoPilotと、Peer to Peer技術によるWindows Update時のInternetからのダウンロードサイズ削減。私のお客様でもWindows 10の帯域制御に四苦八苦されている方が多いので、P2Pによるダウンロードが魅力的だな～と思いました。余談ですが、Teamsのアプリも更新のたびにフル容量ダウンロードなのでなんとかしてほしく。この仕組みに乗ればうれしいです。
DA08 セキュリティマニアックス ～みんなで守ろうコネクテッドカー～
TechSummit 2017で聞いた話とあまり変わらず。
- 自動車のソフトウェア化
- MacOSXよりもコード量多い
- バグなんて避けられない！
- コードセキュリティとは
- プログラム署名をする
- パスワードのハードコーディングをしない
- 自動車のCASE化
- Connected
- Autonomous
- Sharing
- EV
- この4つを抑えればハッタリが効かせられる
ガチで守るのなら生産工場の現場からセキュアにしなければ、という話。
DA13 組織のデータ活用術～Power BIとAzure Machine Learningではじめるデータ解析実践編
7割くらいがAzureMLの話で、残り3割がPowerBI。新卒採用のデータと、3年後の社員のデータを比べて、有能なグループを定義するとか。すいません、ちょっと期待している内容と違ったのでピンときませんでした。MLはできないけど、PowerBIでもRDBのように設計して分析ができるらしく、そこから取り組んで行こうかなぁ…と思いました。
CI01 帰ってきた インフラ野郎 Azure チーム ～Azure データセンター テクノロジー解体新書 2018春～
Azure データセンターの裏話。海底テーブル引いてるとか、今までのAzure物理マシンの遍歴。Available Zoneの話。Cloud Shell使いましょう便利ですよ、の話。物理マシン、IaaSの話だが…そこらへんを意識したくなければPaaS使いな！とのことでした。
参加できなかったもの
日程やら満席やらで参加できなかったもの。あるいは、資料公開されたら念のためチラ見したいもの。資料公開されたら感想を書いてきます。
- AI19 Cognitive Services 最新情報 @ Build 2018 を一気にチェックする50分！ [AI18 と同一内容]
- AD36 実録 クラウドネイティブへの道：PaaS Firstで限界を超えろ！
- AD28 ワタシハ Azure Functions チョットデキル
- CI17 「Azure のセキュリティと言っても範囲が広すぎるので、どこから手を付けたら良いのか分からない！」という方のためのセッション
- AD18 ノンコーディングでサーバーレス体験。Azure Logic Apps のすゝめ
- CI09 クラウド アーキテクトへの道 ～ 基礎から学ぶサービス利用設計
- AD21 開発者におくる Power BI を使う時に考えるべきアーキテクチャ ～ データを溜めるのは誰だ？ ～
- AD03 使い倒そう Visual Studio Code! -アプリ開発から遠隔ペアプロ、コンテナー管理、クラウド連携まで-
- CI03 AD FS では守れない？！アカウント乗っ取りを防ぐためにすべき 3 つのこと ～ユーザー企業の実例のご紹介～
- AD33 今更聞けない！？Microsoft Graph で始める Office 365 データ活用と事例の紹介
- AI03 AI 活用の一歩を踏み出したい皆様に贈る Cognitive Services & Bot Framework はじめてみた物語
- CI18 あなたの組織はなぜ忙しいのか？～Workplace Analyticsで組織変革にチャレンジ～
- AD15 NoOps へ舵を切れ ～ Azure で実現するサーバレス自律運用システム
- AD01 試作で止まらないための チャット Bot 開発
- AC15 Windows 10 April 2018 Update の内容をまとめて紹介！
- AD26 Serverless と NoOps が実現する近未来
- CI16 Web API も狙われてる?? 使いこなそう今ドキ WAF
- AD42 あとで困らないための Azure Active Directory 連携開発 A to Z
- DA18 ブロックチェーンの未解決問題と仮想通貨のセキュリティ
- AD20 実践から学ぶ！SNS ID を企業認証基盤で活用するには？
- CI07 もうセキュリティはやりたくない！！ ～ Microsoft ATP で実現するサイバー攻撃への「本当」の運用の仕方～
- AD20 実践から学ぶ！SNS ID を企業認証基盤で活用するには？
- AI01 コンテンツ/文書をより探しやすくするための Search x AI - Cognitive Search -
まとめ
専門外の話が多くて苦戦したけど、分かってる話を聞いてもしょうがない、という上でのチャレンジだったので楽しめました。家に帰っていろいろと触るまでがde:codeとのことなので、ちょくちょく手作りしていこうと思います。
Azure 仮想マシンをHTTPトリガーで起動/停止/サイズ変更などする
表題のような要件が生まれたのでやってみます。
前準備
Azure Powershellに自動ログインできないと始まりません。
以前、こんな記事を書いたのですが…
Azure上に作成した仮想マシンを作業時だけサイズ変更して快適に利用する(その他仮想マシン作成後のメモ) - 今日も元気にIT屋さん
セキュリティ上の理由でこの方法が使えなくなったので別の方法でやります。
1. Azure Active Directory に、空のアプリケーションを作成し、アプリケーションの ID とパスワードを作成する
手順の通りに実行します。アプリケーションを作成し…シークレットキーを生成。
会社アカウントの場合、システム管理者が一般ユーザーがAzureポータルにログインできないよう、制御している可能性があります。その際はあきらめましょう。
2. 入手したアプリケーション ID とパスワードを認証情報にする
Azure にサービス プリンシパル名を登録します。という手順で躓きました。ブログの記載では
New-AzureRmRoleAssignment -ServicePrincipalName http://myTestApp -RoleDefinitionName Contributor
とありますが、"The provided information does not map to an AD object id."というエラーになる。いろいろ調べたところ、時間が解決するという書き込みもありましたが、以下のように直接アプリケーションIDを指定する事で登録が出来ました。
New-AzureRmRoleAssignment -ServicePrincipalName [アプリケーションID] -RoleDefinitionName Contributor
参考にした記事：Use PowerShell to create a Service Principal in your AAD
3. Azure PowerShell からログイン
後は元記事の手順通りにログインが出来ます。
$secpasswd = ConvertTo-SecureString "[シークレットキー]" -AsPlainText -Force $AppID = "[アプリケーションID]" $TenantID = "[テナントID]" $mycreds = New-Object System.Management.Automation.PSCredential ("$AppID", $secpasswd) Login-AzureRmAccount -ServicePrincipal -Tenant $TenantID -Credential $mycreds[f:id:teraco:20180424175225j:plain]
HTTPトリガーから起動/停止/サイズ変更など
1. Azure Functionへの登録
上記PowerShellをAzure Functionに登録し、HTTPトリガーで動くようにします。
HTTPトリガーは以下のようなURLにアクセスすることで動作させることが可能です。
https://[アプリケーション名].azurewebsites.net/api/[関数名]?code=[functionキー]
HTTPトリガーの種類を"匿名"にすればcode=～の部分は不要です。が、セキュリティを高めるために、規定値で使用するのがいいでしょう。functionキーの表示兵法は、関数レベルの管理メニューからホスト キー(すべての関数) -> defaultを表示すればOK。
2. 引数受けの準備
指定したサーバーに対して、起動/停止のアクションを実施したいため、サーバー名とアクション内容を指定できるようにします。HTTPトリガーにGetで引数を投げた場合、以下の変数で受けることができます。
$req_query_[引数名]
今回は、サーバー名 = server、アクション内容 = modeで受けるため、以下のようなURLでGetリクエストを投げ…
https://[アプリケーション名].azurewebsites.net/api/[関数名]?code=[functionキー]&server=[サーバー名]&mode=[開始]
スクリプト中では以下のようなコードで受けます。
$mode = $req_query_mode if($mode -eq $Null) { "Please set mode Param(stop/start)" exit } $Server = $req_query_server if($Server -eq $Null) { "Please set Server Param" exit }
3. PowerShellの登録
サーバーを起動/停止するpowershellコードを書きます。
$RGName = [リソースグループ名] if($mode -eq "start") { Start-AzureRmVM -ResourceGroupName $RGName -Name $server } elseif($mode -eq "stop") { Stop-AzureRmVM -ResourceGroupName $RGName -Name $server -Force }
前準備を行う事でAzure PowerShell への自動ログインが可能となったので、自動ログイン後、仮想マシンに対してアクションを行うPowerShell スクリプトを作成します。ここでは仮想マシンの起動を行うようにします。
4. 資格情報の隠ぺい
これだとスクリプトの中に資格情報が記載されたままで怖いので、上記参照記事の通り、Functionの機能を用いて隠ぺいします。
Connect an Azure Function to Office 365 - GCITS
文字列を暗号化すると…
ファイルが生成される。
PassEnctyptKey.key をアップロードし。
EncryptedPassword.txt 中の文字列を環境変数に設定。
隠ぺい前はこちら。
$secpasswd = ConvertTo-SecureString "[シークレットキー]" -AsPlainText -Force $AppID = "[アプリケーションID]" $TenantID = "[テナントID]"
隠ぺい後はこちら。
$FunctionName = [関数名] $keypath = "D:\home\site\wwwroot\$FunctionName\bin\keys\PassEncryptKey.key" $secpasswd = $Env:SecretKey | ConvertTo-SecureString -Key (Get-Content $keypath) $AppID = $Env:AppID $TenantID = $Env:TenantID
Office 365 Multi-Geo(マルチジオ)機能について
Office 365 Multi-GeoがGAしたぽいのでまとめてみます。
使用条件
以下の製品ライセンスが適用されたユーザーが5,000ユーザー以上のOffice 365テナント。
- Microsoft 365 F1, E1, E3 or E5
- Office 365 F1, E1, E3 or E5
- Exchange Online Plan 1 or Plan 2
- OneDrive for Business Plan 1 or Plan 2
- SharePoint Online Plan 1 or Plan 2
5,000ユーザー以上、という書き方をしていたので、ライセンス混在でも問題なさそう。
対応製品
- Exchange Online
- OneDrive for Businesss
今後、SharePoint OnlineとGroupsへの対応を予定している、とのこと。なぜOD4BとSPOのリリースタイミングが違うか謎。サイトライブラリへの対応が難しかったから?
設定方法
- 使用条件を満たしたうえで、マイクロソフト社営業に連絡
- マイクロソフト社にて認可後、Office 365 MessageCenterにてマルチジオ有効の通知が来るまで待つ。目安は数週間。
- OneDrive管理センターよりメインサイト以外にデータを保有するサテライトを選択(Exchange Onlineのみの場合は不要)
- Azure AD Powershellより、サテライトサイトにデータを移動したいユーザーに対してユーザー属性"PreferredDataLocation"を設定する(クラウドIDユーザーの手法。オンプレから同期したユーザーは別の方法で選択)。選択可能なロケーションは2018/4/18現在、以下の通り。
| Geo | Code |
|---|---|
| Asia/Pacific | APC |
| Australia | AUS |
| Canada | CAN |
| European Union | EUR |
| India | IND(※) |
| Japan | JPN |
| Korea | KOR |
| United Kingdom | GBR |
| United States | NAM |
※ Indiaは現状メインサイトのみ選択可能
Azure AD Powershellにて設定した”PreferredDataLocation”の通りに、Exchange Online、Onedrive for Businessのデータがサテライトサイトに移行される。ExOLとOD4Bのデータを別々のサイトに保管することはできない。そんな用途はないが…。
料金
- サテライトサイトに所属するユーザー数×2ドル/月
リソースメールボックス、共有メールボックスは無料。5000名のユーザーで100名だけフランスなんすよ～な企業は100ユーザー分しか料金かからないので、積極的に使用するべきじゃないでしょうか。
※ テナント全体の5%以上のユーザーがサテライトユーザーじゃないとだめって縛りがある様子。
注意点・制約事項
- パブリックフォルダとOffice 365 Groupsはメインサイト以外に選択できない
- eDiscovoeryで監査したデータはメインサイトに保管される
- サテライトサイトのユーザーはOWAの"別のメールボックスを開く"機能でメインサイトの共有メールボックスにアクセスできない。
- サイトを跨いだカレンダーの委任は、OWAでは機能しない。Outlookでは機能する。
- サテライトサイトのユーザーの管理をコマンドラインから行う場合、明示的にサテライトサイトにログインした方が処理が速いため推奨
同期ユーザーをサテライトユーザーとする場合の注意点
- Azure AD Connectのバージョンは1.1.524.0以降
- オンプレミスADには"PreferredDataLocation"属性が存在しないため、ExtentionAttributeなどを任意のテキストを挿入可能なカラムを代替の属性としてマッピングする必要がある
- 詳細な手順は以下
