バッチサーバー、Azure functions、LogicApps、Flowの違い

ひょんな事から kenakamuさんとお話しする機会があり、自分なりに整理できたのでメモ。

背景

Azure functionsにも慣れ「これがサーバーレスかー!おもろー!」とコードを書きまくって動かしていたところ、コードの行数が200行を超え、コードから呼び出すためにfunctionsにUPするモジュール(Azure Powershell)なども増え、コードとモジュールの管理が必要となる。「これってバッチサーバー上で動かしているのと、何が違うんだろう…?」と思ったのが、考えるきっかけです。

また、LogicAppsとFlowの違いを説明することが多いので、まとめようと思いました。

比較表

バッチサーバー Azure functions LogicApps Flow
料金 ○無料 ○無料 ×有料 ○無料
簡易さ ×コード ×コード ○GUI ○GUI
自由度 ◎自由 ○自由 △サービスの制約あり ×サービスの制約あり
時間制限 ○なし ×あり ○なし ○なし
基盤 ×IaaS ○PaaS ○PaaS ○PaaS
安定性 ○高 △中 ×低 ×低
権限 ○管理者 ○管理者 ○管理者 ×ユーザー

料金

LogicAppsはステップ毎に課金が発生。バッチサーバー、Azure functions、Flowはあえて”無料”と書かせていただきましたが、バッチサーバーはサーバー費用、Azure functionsは実行回数とCPU時間による課金、Flowは500回/日の回数制限があります。

ただ、ちょっと動かすだけならfunctionsとFlowは無料で使え、バッチサーバーも環境がある場合(ほとんどある)は、実質無料で使えます。

簡易さ / 自由度

LogicAppsとFlowはGUI、バッチサーバーとAzure functionsはコードで動かす必要がある。GUIの場合、設計書がなくてもある程度意味が分かるのが大きなメリット。つーかお客さんが設計書なしでもOKと言ってくれる。もちろん、作成の背景を記した要件定義書は残しておいた方がよいが…。一方、コードの場合、プログラムができない顧客に引き渡すとき & 自社管理用にプログラム設計書はほしい。GUIなら気軽に変更でき、それが設計書となることから、Logic Apps、Flowの方が、気軽にあれこれいじれるメリットはある。

その簡易さと引き換えにコードには自由度がある。バッチサーバーはIaaS環境を自分でいじれるので自由度◎、Logic AppsはAzure functionsと連携できるので自由度△としました。

時間制限

これはAzure Functionだけの制約で、1回の実行時間が5分(工夫すれば10分)となる。5分あればある程度の処理は出来るが…。一方他は実質時間制限なし。

基盤

バッチサーバーはIaaSとなり、基盤の再起動タイミングなどを考慮して設計することが必要。

安定性

LogicAppsやFlowは(実績ベースだと)起動に失敗し、うまく動かないことがある。一方、IaaS上でタスクスケジューラーやJP1で動かす場合、ほぼ確実にプログラムがキックする。…という意味で、こういう評価にさせてもらいました。Azure functionsの実績は手元にないので、とりあえず”中”にしました。

権限

Flowだけがユーザー権限であり、ユーザーが自分が出来る範囲のタスクをFlowで実装するもの。よってLogicAppsが元になっているとはいえ、自分ができないことはFlowにも出来ないです。(本当に抜け道がないか自分で確認したわけではないけど、設計思想はそう。)

なので「Flowでいろいろできちゃうかもしれないから、禁止しよう!」はナンセンス。まぁ中には、手動で私用のGmailにメールを送るのはいいが、自動転送はシステム的に禁止する、などのナンセンス運用の企業もあるが…。

管理者が実行するスクリプトのための比較表なので、〇管理者 / ×ユーザーとしてしまったけど、ユーザー権限だから逆にいいこともあり、一概には言えません。

ユースケース

Office 365 ライセンス付与、初期ユーザー設定バッチ

Office 365の運用ではほぼ確実に必要なバッチであり、サーバーレスの概念の登場前はバッチサーバーで動かしていたのがほとんどと思われる。これは引き続きバッチサーバーで動かした方がよいのではないか、と思えてきました。

まず、管理者業務なのでFlowは除外。1ユーザー毎に発行するコマンドが多く、LogicAppsで処理すると処理が長くなりそうな事。AzureADのユーザー属性によって処理内容を変化させる必要があり、分岐のパターンによってはコードで実装したほうがスマートであること。コマンドが通らなかった場合の、エラーハンドリングが必要なこと(例外処理が多い)など。

ログ監視バッチ

一定期間毎にクラウドサービスのログにアクセスしてデータをエクスポートする。これはコマンドは単純ですが、ログが大量の場合、APIからの戻り時間が不安なため、バッチサーバーで実行したほうがいいかもしれません。

使い分け基準

1. 管理者が実施するアクションか、ユーザーが実施するものか

これでFlowかそれ以外かを分けられます。

※ ただし、本来管理者が実施する業務だが、無料のFlowを使いたいため、システムアカウント権限でFlowを動かす方法はあり。”本来すべきではない”かもしれないけど。

2. タイマージョブか、そうではないか

もしタイマージョブ以外、例えばHTTPトリガーの場合、バッチサーバー上で動かすプログラムをHTTPトリガーで動かすのは面倒であるため、バッチサーバーは使わない方がよいと考える。

3. 短時間で終わるかどうか

もし5分以内に終わらない、あるいは終わらない可能性があれば、自動的にAzure functionsは候補から外れる。

4. ミッションクリティカルなアクションであるか

1度くらい失敗して、それに気づかなくてもよいかどうか。もしそれがNGなら安定性の高いバッチサーバー or Azure functionsで動作させるべきである。1回失敗しても、翌日に成功 or ユーザーリトライでOKだったらLogic Appsでよい。

5. Logic Appsの標準パーツで大半のフローを実現可能かどうか?

例えばExchange Onlineのユーザー設定は現状GraphAPIも用意されておらずPowerShellからしか行えないため、多数のコマンドを発行するならLogic Appsを使う意味は少ない。

6. 2~5で判断がつかない場合

タイマージョブで、そこそこ短時間で終わり、1回失敗しても翌日リトライすればOK、Logic Appsと2,3のAzure Functionsを組み合わせれば実現可能の場合。その場合にどの製品を使用するかは会社の開発ポリシーによります。例えば、Azure FunctionsはLogic Appsの部品としてのみ使用を許可、それ単体では動かさない、よって20行以上のコードを書くのは禁止する、など。

おそらく社内にコーディング規約的があるとすると1つの関数に実装する機能は1つまでなど、ある程度のポリシーがあるはずです。それと同じことをクラウド製品でも検討する必要があると思います。

まとめ

kenakamuさんがおっしゃっていたのは「なんでもできるからこそ、製品が生まれたニーズを知り、最適な使い方をする必要がある。」とのこと。

私自身、これだけサーバーレスだiPaaSだともてはやされていたとしても、コードを書いて、バッチサーバーで動かす方がいい場合もあると思いました。

Office 365 管理者アカウント 強制MFA機能(Baseline security policy)と対処法

最近がんばってるAzureADチームがナイスな新機能をリリースしてくれました。

Baseline security policy for Azure AD admin accounts in public preview! – Enterprise Mobility + Security

  • 全体管理者
  • SharePoint 管理者
  • Exchange 管理者
  • 条件付きアクセス管理者
  • セキュリティ管理者

上記権限を保有し、かつMFAが有効になっていないアカウントについて、強制的にMFAが有効になります。これらのアカウントをスクリプトで使用していたり、共用で使用している場合は、運用上支障が出ます。

対処法

その1. 機能を無効化する

この機能はプレビューであり、GAされた段階で強制MFAが発動します。それを防ぐためには以下画面で「ポリシーを使用しない」を選択します。

f:id:teraco:20180626231956p:plain

その2. MFAを有効にしないアカウントを選ぶ

MFAを使わないアカウントが整理できている場合、同じ画面から除外対象アカウントを指定できるので、MFAを有効にしないアカウントを指定します。

なお、他の選択肢として「全ての管理者アカウントでMFA有効化」がありますが、この設定を使用すると後述の通りスクリプトでの管理タスク実行に支障が出るため、現実的には「MFAを除外するアカウント指定」を使用するべきでしょう。MSも「全てのアカウントについてMFAを利用するのではなく、緊急用の管理者アカウントを1つはMFAをオフにする方法」を提示しています。

Manage emergency-access administrative accounts in Azure AD | Microsoft Docs

さらっとしか流し読みしてませんが、パスワード文字列を2つか3つに分けて、別々の人間が知るようにする、などが書かれています。

SIer的な立場として

こんなうざったい機能がリリースされたからオフにしちゃいましょうはアウトな気がします。今までは規定値がMFAオフだったので許されていたかもしれませんが、今後は規定値がオンなのをオフにするので…。

  1. SIerが明示的にMFAオフにする
  2. 結果、アカウントが乗っ取られる
  3. SIerが悪いんじゃね?

という話になりそうな気がします。最低限、説明責任を果たして、顧客の同意を取ってからオフにするべきでしょう。

推奨設定

といってもスクリプトで管理者アカウント使いたい!という人向けに推奨設定が出ていました。

Securely Administrate Exchange Online with Multi-Factor Authentication (MFA) – Microsoft Tech Community – 207160

対話的に使用する管理者アカウント

人間が非定形作業で使用するアカウントは(ちょっと面倒ですが)二要素認証を有効にします。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を求められ、スクリプトでのアクセスが不可になります。時限爆弾。

f:id:teraco:20180626232129j:plain

f:id:teraco:20180626232131j:plain

余談:MFAの実装方法とGA時期予想

KBの注意書きに、MFAが有効になった管理者アカウントは、POP/SMTP/レガシーのOutlookクライアントからもアクセスがブロックされるよと書かれていました。これは検証していないですが、この注意書きが正しいとすると、最近Azure AD Premiumのプレビュー機能として実装されたレガシーブロックの機能を利用していると考えられます(旧MFAはレガシーブロックできなかった…はず)。ということは、Azure AD Premiumのレガシーブロック機能がGAされるまで、Baseline security policyも有効にならないのかな?と思いました。

Azure AD スマートロックアウトのカスタマイズ機能について

こんなリリース(プレビュー)がありました。

cloudblogs.microsoft.com

機能としては3つで

  1. ロックアウト閾値の変更
  2. 禁止パスワードの定義
  3. オンプレADのパスワード保護

となります。1と2は以前からGraphAPI経由で変更できた機能です。

docs.microsoft.com

3は新しくリリースされました。

1. ロックアウト閾値の変更

Azure ADのロックアウト値は規定で

  • 10回連続でパスワードを間違えた場合
  • 60秒間ロックアウトがかかる

です。この値を変更できます。

この機能の何がうれしいの?ということですが…。

例えば、社内のセキュリティ部門が定めているポリシーでパスワードは3回連続間違えたら1時間ロックアウトすべし!と決まっていて、Azure ADが導入できない場合など。あるいは、外部からアタックされてもアカウントが即ロックしないように、100回連続でパスワードを間違えてもOKにしたい、など。前者はセキュリティ重視、後者は利便性重視ですね。

余談

MSとしてはAzure ADで提供している

  1. ブラックリストIP
  2. IPロックアウト
  3. スマートロックアウト

の3つの機能で、利益目的の攻撃者のアタックをほぼ防げる、と主張しています。1はそもそも怪しい所からのアクセスは禁止する、2はパスワードスプレー攻撃への対応、3はブルートフォース攻撃への対応です。そこらへんのロジックはMS本社のSIMONSさんの神エントリをご覧ください。

Azure AD and ADFS best practices: Defending against password spray attacks – Enterprise Mobility + Security

てことで、利便性重視の設定にしてしまって問題ないと思われます。

具体的には、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?何それ?

まとめ

そんな感じで今回も非常に面白かったです。主催者のもくだいさん、お菓子係のみなさま、ありがとうございました。次回もぜひ参加できればと思います。