Teamsとskype、Yammerの違い。Teamsへの不満。

SkypeがTeamsに統合されるとか、TeamsがあればYammerは必要ないんじゃない?とかいろんな声がありますが、少し語ってみます。Teamsは1チームに○○人参加できてYammerは…のようなスペック比較はしません。

なおここで書く機能は変更されているかもしれないので、最新情報はMicrosoft Teams Blog – Microsoft Tech Communityをご確認ください。

SkypeとTeamsの違い

将来的にSkypeの機能はTeamsに統合されるのでTeamsを使わざるを得ず、比較してどちらが優れているか結論を出す意味がないです。よってここではTeamsを使うことを前提に、SkypeにあってTeamsにない機能、つまりMSさん、まーじでこの機能をTeamsに実装せんかったら許さんぜよという機能を上げていこうと思います。

1.状態変更通知のマーク

Skypeには”状態変更通知のマーク”という機能があります。

誰かの状態が変わったときに通知する – Skype for Business

これは連絡先一覧に登録したユーザーのプレゼンスが変化したときにポップアップを出す機能です。具体的な使いどころとしては、中々連絡がつかない上司を”状態変更通知のマーク”しておいて、”連絡可能”になった瞬間にポップアップを表示、素早くIMする or 話しかけにいく、などです。

f:id:teraco:20180309230216j:plain

f:id:teraco:20180309230219p:plain

あまり管理したくないタスクの1つに「○○さんに××を伝える」というのがあります。口頭で伝えると10秒で済むけどメールを書くとなると面倒。とはいえ、○○さんは不在のことが多く、○○さんを見かけたら話しかける、というタスクを常に意識する必要がある。

こういう時に”状態変更通知のマーク”機能を使うと、“連絡可能”になった瞬間にポップアップが表示され、リマインダー代わりになり、タスク管理の必要がなくなります。用事を口頭で済ますことで、メールを書いてお互いが疲弊することもなく、効率的。Skypeの機能を一番有効に利用している機能だと思います。

2.連絡先一覧

1.状態変更通知のマークが実装できないのは、Teamsに連絡先一覧の機能が存在しないからなんですよね。Skypeの場合、Outlookのようにユーザーを”連絡先”に登録する事ができ、そうするとアプリを立ち上げ連絡先一覧ビューを表示すると、登録したユーザーの一覧とプレゼンス一覧が表示されます。

[画面]

この機能のおかげで、Skypeアプリが連絡先に登録したユーザーのプレゼンスをウォッチし、状態の変更をトリガーに通知できるわけです。それ以外にも、ユーザーをカテゴライズし、仲のいい同僚は自分のプレゼンスが”応答不可”でも連絡OKにするなどできます。

3.複数ウィンドウ対応

SkypeがPC-モバイル間連携イケてないのと同じくらいイケてないと思うのですが、Teamsは現状マルチウィンドウに対応していません。つまり、Teamsで作業中、誰かからのIMを受けてしまうと、作業画面からIMの画面に遷移し、作業画面が閉じられてしまうのです。IMに返信した後、作業画面に戻ると、またIMが来て作業画面が閉じられる。非効率すぎてヤバいです。1つのアプリに機能を詰め込みすぎた弊害です。

4.アプリケーションの反応速度

遅いですよね、Teams。速度だけならSkypeの圧勝です。Webの世界ではページを開いた時のレスポンスが1秒遅れると30%のユーザーが離脱する言います。つまり1秒レスポンスが遅れると3割ほどのユーザーがストレスに感じるわけです。速さは正義。OA製品の世界で速さはあまり重視されませんが、もっと真剣に考えてほしいです。

噂だと、今のTeamsクライアントと兼用できるSkypeライクな軽量版Teamsクライアントがリリースされるらしいので、それがリリースされたら3と4は解消するかもしれません。けど、1と2はほんまに実装してほしいです。

YammerとTeamsの違い

一言でいうと、

で、似ているようで全然違うと僕は思います。

職場内のつながり・人との距離感

まずYammerは人との繋がりが広がります。TOPページにアクセスすると、自分が加入していないグループの投稿がレコメンドとして表示されます。面白そう、関係ありそうなグループを見つけることが簡単です。Teamsは全然広がりません。自分が加入しているチーム以外の投稿は一切表示されません。

Yammerの方が、ユーザーの人となりを感じることができます。なぜなら、よくYammerでやり取りする人の投稿は、自分が入っていないグループでもレコメンド機能でTOPページに表示されるし、アカウントをフォローして表示を多くすることもできるからです。自分の後輩が、自分が含まれたグループだとメンバーに対して敬語だけど、社内の業務外の集まりのグループではタメ語でリラックスしている、自分の知らない後輩の人となりも分かります。

Teamsはチームに参加している後輩の顔しか見えず、人となりがわからないです。なぜなら、チーム内でよくやり取りしても、チーム外の情報は一切分からないし、アカウントをフォローする事も出来ないからです。知らない側面は知らないままです。

よってYammerでよくやり取りする人は、個人同士の距離がより縮まっていく。Teamsはミッションだけの関係で、チームが解散したら繋がりも切れます。

情報の拡散

Yammerは投稿単位でURLが発行されるので、価値ある情報はURLを拡散することで広げることができるし、Yammer内ならリツイートでグループを跨いで拡散できます。Teamsは投稿単位でURLが発行されず、またチャネルの外に投稿を拡散できないので、情報を広めるのが難しいです。

twitterとLINEに例えると、twitterの1つの投稿がバズれば、リツイートでどんどん広がるし、投稿のURLも拡散していく。LINEグループ内で面白いことを言っても、グループ外部の人はその情報にアクセスできないので、グループ内で閉じられた情報となります。

非公開グループの仕様

Yammerで非公開グループを作成しても、検索でヒットすればグループが存在すること自体はわかってしまいます。なのでグループ名に「社長を失脚させる会」とか書いてるとヤバいです。Teamsは非公開グループなら検索でも引っかからないので安心です。また、Teamsは公開グループでもグループに参加しない限り情報(※)を見ることができない。グループに参加したことはログに残るため、いつの間にか知らない人にグループのやり取りを見られた、ということは発生しないです。

以上をいろいろ踏まえて。Yammerにグループを作るならYammerの性質を最大限生かせるように”公開”でグループを作成すべきだと思います。というか、Yammerで非公開グループ作るならTeamsで作れよ、って話です。YammerかTeamsかどちらにグループを作るか迷う場合、フォロー外から失礼されてもOK
むしろ歓迎ならYammer、そうじゃないならTeamsという感覚でよいと思います。

ということで、YammerとTeamsについてはどちらも特徴があるので1つに統合されなくていいと思うのですが、Yammerをサービス提供し続けるのなら使い物にならないゴミ検索機能はなんとか改善してほしいです。

※ 正確には、チャネル内のチャットは見れないが、TeamsのSharePoint領域に保存されたファイルの直リンクを持っていれば閲覧可能

Teams不満点

メールを捨ててTeamsに移ろう!と試みた時の不満点を書きます。

1.タスク管理機能がない

Outlookの場合、着信したメールに対して

  • 関係ないからゴミ箱行
  • 仕訳ルールでフォルダ振り分け
  • アラート設定で翌日ポップアップが出るようにする
  • 分類を割り当てて管理
  • 未読ステータスのままにして、後日対応

などいろいろやり方はあるのですが、Teamsの場合「投稿を保存する」しか管理機能がない。Outlook捨ててTeams使ってる人、これマジどうやってんすか…?

2.スケジューラー連動ができない

「1.タスク管理機能がない」でも書きましたが「このメールは15時からのMTGで内職するから15時にポップアップが上がるようにしとこ」ができない。

3.マルチウィンドウができない

「3.複数ウィンドウ対応」でも書きましたが、Teamsの中で全て完結させる思想のため、Excelなども内蔵ビューワーで開いてくれます。それはそれでよいのですが、Excel開いた後に、別のチームでやり取りしてる会話参照して~その会話で言及されてるパワポ開いて~Plannerで進捗確認して~となると、ちょまちょま無理やんけ、となり、外部のExcelPowerPointを開く羽目になる。

いままでパワーユーザーが自分なりにツールの機能を利用していたのが、なまじTeamsに機能が統合され、かつTeamsの自由度が低すぎるために結局、現状Teams1つでは不十分である、と言えます。

Monthly Office 365 Update (2018年1月、2月のブログ記事)

Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。読んでたブログ記事で気になったものをメモ。

ブログ記事

AzureAD

cloudblogs.microsoft.com

AzureAD B2Cに関する改善点。パスワードの強度を設定できるようになった事、監査ログの出力、複数のSNSアカウントとの連携可能(既に連携済みのSNSアカウントから別のにチェンジもOKなど。

EM+S

cloudblogs.microsoft.com

2月のEM+S系まとめ。その中で気になった事は以下。

cloudblogs.microsoft.com

CloupAppSecurityで同一SaaS製品の複数のテナントに対応しました。例えばですが、Boxのテナントが部署ごとに分かれている場合は、すべてを管理できたりするのかな。

cloudblogs.microsoft.com

AzureADJoinしたWin10端末から、オンプレのプリンターにSSOしてプリントできる事。ご存知の通り、AzureADJoinのためにはオンプレADから離脱する必要があり、ファイルサーバーや物理プリンターにシングルサインオン出来なくなります。これを無理やり、Windows Hello for BusinessでSSO環境作る事は出来るのですが、プリンターとファイルサーバーという課題の1つがこれで解決した、という事になります。まぁファイルサーバーはSPOに持っていけ、という話で決着するやろな…。

cloudblogs.microsoft.com

O365グループに指定したプレフィックスを付与できる機能です。例えば、”Group-“を頭文字につけるとか。Azure ADP1以上が必要。これ以外にも、最近リリースされたGroups(Teams)関連の機能はP1が必要である場合が多いので要注意。

cloudblogs.microsoft.com

IntuneAPIがGAしたよ、という話。去年の秋くらいからGitHubにコードが上がっていましたが、今回正式にドキュメントも整備されたようです。これでIntune関連の運用を自動化する事ができるので、技術力さえあれば提案の幅が広がりそうですね。

Teams関係

techcommunity.microsoft.com

Teamsにskypeの機能を乗せ換えるロードマップ。だいたいスケジュール通りに行ってるっぽい。

techcommunity.microsoft.com

techcommunity.microsoft.com

1月と2月のTeams更新内容。地味に機能UPしてたりするので、目を通しておくのがいいでしょう。ちなみに私が最近不便に感じることで、iOSのTeamsアプリでスタンプが使えない、というのがあります。Teamsの公式ページ見ると堂々と”未対応です”と乗っていたので対応おなしゃす…。

その他

azure.microsoft.com

AzureFileShareの機能を使ってオンプレサーバーのファイルをバックアップする方法。全部マネージドサービスでやり切れて、今流行りのサーバーレスアーキテクチャーみたいになってます。

azure.microsoft.com

ExpressRouteの使用帯域をモニタリングできるようになりました。で、早速確認しようと思いましたが、ログインできる環境のER回線がまだクラシックポータルから移行で来てなかったです…。

Office 365 Education で次世代イノベーションに向けた包括的な共同学習機能を提供 – Office Blogs

これ、いいなって思ったのがOneNoteにロック機能がつく、という話なんですね。Education版限定の機能という事ですが、普通のOneNoteにも実装してほしいです。

Monthly Office 365 Update (2018年1月分,2月分)

Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。12月が少なくて油断してたら空いてしまった。

チェックソース

Office 365 メッセージセンター

MC127367 OneDrive for Business Files Restore

誤削除やランサムウェアとかにやられてOD4Bのファイルをある期間まで戻したい場合に出来るようになりました。今までも個別のファイルにバージョン履歴がついて戻せるってのはあったけど、日付指定で一括して戻せるからリストア用途に便利って事かな。

MC127442 Updated feature: Microsoft Forms

FromsがGA。Froms、結構便利に使ってまして(飲み会のアンケートとか)。Flowと連携して承認機能付きワークフローも作れるので面白いのですが、それがお金取れるか、実際に業務に組み込めるかというと、GAしたばかりでは(仕様変更ありそうで)ちょっと怖いかな。

MC127900 OneDrive for Business File Hover Card

ブラウザからOD4Bにアクセスすると、ファイルにマウスを当てただけでアクセス数とか誰がそのドキュメントを見たかの詳細情報が分かるよ、という話。Delveぽいイメージ。

MC128111 File Move in SharePoint Online and OneDrive for Business

異なるユーザーのOD4B、SPOのライブラリでファイルを移動した際に、元のファイルのメタデータと変更履歴を引き継ぎ、復元などを可能にする機能。

MC128792 Azure Active Directory Administrative Units

気になる機能。ユーザーのAAD属性をキーにとあるAdminで管理可能なユーザーのスコープを絞る事が出来る機能。例えば親会社と子会社が同じO365テナントに入っている場合、親会社がExOLの管理権限を持つと子会社のユーザーの設定を勝手に変更出来てしまって問題、などがありましたが、この機能を使う事で制御できます。

実はオンプレExchangeで、OUなどをキーに管理ユーザーを分離できる、という似たような機能があってこれが実装されたと考えていいのかな。ただオンプレExchangeの場合、メールの監査検索などユーザーに対して横断的にアクセスする機能は管理分離できなかった気がするので、この機能でも監査ログの閲覧などはテナント全ユーザーのものが見えてしまうでしょう。

なので、完全分離とはいかないです。やることでかなりの効果があるのか、やらないよりはやった方がマシなのかは、チェックする必要あり。

Working with Administrative Units | Microsoft Docs

MC128924 See Microsoft Planner tasks in iCalendar

プランナーのタスクをiCalにエクスポートできるようになった、という話。これでなんとかOutlookでPlannerの予定を見れるようになった…ってもっと他にやり方ないんかい。しかもこの方法だとiCalが読める外部のOutlookでもPlannerの予定見れてしまうのでもしかして情報漏洩に繋がるんじゃない???つまりPlannerに社外秘情報を書いてiCalに持ち出すってやつ。僕のアカウントでこの機能が使えなかったので試せてないですが、懸念ですね…。防ぎ方はこちらの様子。

組織のプランナーで Outlook 予定表の同期をオフにします。 – Office サポート

MC128929 We are moving to TLS 1.2 for encryption

ご存知の通り。10/31に延期になりました。

MC129312 Manage calendar delegate permissions in PowerShell

これ、むちゃくちゃ重要な変更じゃないですか。一見、何が変わったか分からなかったのですが、Add-MailboxFolderPermissionコマンドでスイッチパラメーター”SendNotificationToUser”が実装されたらしい。規定値は$Falseでユーザーへの通知なし。これを$Trueにすると、AからBに予定表の閲覧権限を与えるというコマンドの場合、AからBにシェアリングインビテーションメールが送信される動きとなる。

OutlookからユーザーAがユーザーBに「私の予定表を見ていいよ」って権限を与える場合、

  1. AがA自身の予定表の権限にBを追加する。
  2. AからBに、予定表閲覧の招待状を送信する。Bがクリックする事で、Aの予定表権限にBが追加される

の2通りがある。今まで、Add-MailboxFolderPermissionでは1の動作でしか権限を付与できなかったが2の動作も出来るようになった。

「いやいや、余計なメールを送らず、静かに権限だけ付与できる1の方がいいでしょ」ってのが今までのExOL技術者の共通認識だったんだけど、2の方法で予定表共有をすることで、Outlook for iOSから他人の予定が見れるようになったり、2018年夏に予定されている新しい予定表共有ロジックが有効になったりします。

なので出来れば2で行きたいんだけど、2の場合、ユーザーオペレーションが発生してしまうので、簡単にはユーザーリリース出来ず悩みのタネだった。今回、SendNotificationToUser = $trueとすることで2の動作が再現できるのなら、ユーザーオペレーションがかなり削減され、導入が現実的になる…といえる(ただ、送られたメールをぽちぽち承認しないといけない、という問題はあるが。

MC129699 Compliance Manager is now available

そんなのあったなぁ…と忘れていたコンプライアンスマネージャーがGA。EUのGDPR対応で鳴り物入りでパブリックプレビューしたものの、正直、あまり有効な機能ではないと感じています。

MC129777 New ways to govern access of external users are coming to Office 365

Office 365の外部共有のロジックが変わり、ファイル単位・フォルダ単位でアクセス許可を与えることが出来るようになりました。また、実はOffice 365の外部共有の大きな穴であった、EveryOne権限が付与されたディレクトリは外部ユーザーが自由にアクセス出来ちゃう、ってのも修正されるようです。なもんで、今までバグを利用して外部ユーザーがEveryOne共有のディレクトリを見れている状態だったとしたら3/23から見れなくなるので要注意。

MC129787 We’re making it easier to share and join private teams in Microsoft Teams

Teamsのプライベートチームを検索に引っかかるようにしたよ!というちょまちょま案件ですが、クレーム多数によりリリースがOFFになった様子です。良かった良かった。

MC131146 Updated Feature: Collaborate securely with anyone in Microsoft Teams

Teamsにゲストを招待する際、メールアドレスで招待できるようになるよ、との話。Teams関係のリリースはTeamsブログの月1まとめを見たほうがよさそうですね。

その他ブログ情報

長くなったので別エントリに。

Office 365 Groupsを作成できるユーザーを指定するにはAzure AD Premium P1ライセンス以上が必要

タイトルの通りです。

Office 365 Groups運用のセオリーとして、指定したセキュリティグループに所属するユーザー以外は勝手にOffice 365 Groupsを作成させないように設定する、というのがありました。

Office 365 グループを作成できるユーザーを管理する – Office 365

デフォルトでは一般ユーザーでも自由にOffice 365 Groupsを作成する事が出来てしまい、

  • 勝手に変なメールアドレスが有効になる
  • 勝手にSharePointライブラリが作成されてしまう

など情シス視点では不都合があります。なので申請制にしてガバナンスを利かす or ひとまず情シス内で検証するため、情シス以外はOffice 365 Groupsを作成できないようにする事がベストプラクティスとなります。

しかしながら上記制御を行うためには、対象となるセキュリティグループのユーザー全員に対してAzure AD Premium P1ライセンス以上が必要だそうです。私は最近知りました。

Office 365 グループの制御方法について – Exchange ブログ JAPAN

現状、ライセンスがなくてもコマンドラインから設定できてしまいますが、おそらく厳密にはライセンス違反のため注意しましょう…。

Monthly Office 365 Update (12月分)

Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。年の瀬12月分。今月は少ないかも。

チェックソース

Office 365 メッセージセンター

MC126127 Updated feature: New sharing settings in Microsoft Forms

Fromsで作成したアンケートをは以下の4種類の方法で外部と共有できる

  • 共有して共同作業する
  • テンプレートとして共有
  • 回答の送信と収集
  • 結果を共有

このうち「回答の送信と収集」「結果を共有」は現状外部へのリンク送信を禁止するようコントロールする事が出来るが、今後のリリース(12月末予定)で残り2つのリンクの制御も可能となる。

MC126199 We are moving to TLS 1.2 for encryption

2018年3月1日にOffice 365がTLS 1.2に移行し、1.1、1.0が使えなくなります。世の中的に、2018年6月30日でTLS 1.0を使うなよ、というアナウンスは出ていますし、スターバックスのサイトなどは既にTSL1.0/1.1が無効化されています。

ので、Office 365が特別な対応をしているわけではないのですが、得てして企業システムはレガシーなシステムが動いている事が多いので注意が必要です。

気になるのは

  • プロキシサーバー
  • MTA
  • ADFS/AADCなど

でしょうか。MSは”TLS1.0/1.1での接続はほぼない事を把握している”と言っていますが、それなら管理者がポータルから状況を確認できるような仕組みを作って安心させてほしい…。O365セキュリティスコアとかの前に…。

Windows Hello for Business ハイブリッド キー信頼構成で実現する、Azure AD Join端末からオンプレADへのシングルサインオン

このエントリではTechSummit 2017で実施した展示の技術解説を行おうと思います。といっても展示するシステム自体、テクサミ1週間前くらいから急ピッチで構築して「とりあえず動いた…。もう触らんとこ…」であり仕組みまで深堀出来てません。そんな浅い理解ですが、ナレッジはナレッジなので展開し共有します。

目次

  • Windows Helloとは?
  • Windows Hello for Businessとは?
  • (余談)PIN・パスワード・生体認証の安全度考察
  • Windows Hello for Business ハイブリッド構成のパターン
  • Windows Hello for Business ハイブリッド キー信頼構成の構築手順
  • なぜWindows Hello for Business ハイブリッドでAzure AD Join端末からオンプレADにSSOできるのか

Windows Helloとは?

パスワードの代わりに、PIN/生体認証でWindows端末にログインする仕組みです。

f:id:teraco:20171229143302j:plain
f:id:teraco:20171229143304j:plain

Windows Hello for Businessとは?

ざっくりいうと、ポリシーを利用してPIN/生体認証でのログインを”強制する事が出来る”機能です。”強制する事が出来る”というのがポイント。

“ユーザーの希望に応じてPIN/生体認証でWindowsログインできるようにする”という要件を満たすだけならWindows Helloでよいのですが、Windows Helloの欠点はユーザー自身が設定しないとPIN/生体認証でログインできない事です。

情シス視点で

  • ポリシーを強化し、パスワードを複雑にしたい
  • それだけだとパスワードをメモして付箋で貼り付けるユーザーが続出する
  • なので、PIN/生体認証を利用してパスワードを利用せずWindowsログインできるようにしたい

という狙いの場合、単純にWindows Hello環境を整えてユーザーに設定手順書を渡しても「あ~、情シスから設定してくれってメールきたんだけど、よく分からないし指紋登録とかヤだから、今まで通りパスワードでログインしてるよ」となるのは容易に想像できます。

Windows Hello for Businessなら、グループポリシーでパスワードの複雑性を定義するのと同じ感覚で、ドメイン参加後にPIN/生体認証の登録画面に飛ばす事が出来ます。

具体的には以下の動画をご覧ください。

Windows Hello for Business: What’s New in 2017 – BRK2076 – YouTube

実はこのPIN/生体認証登録はスキップする事が出来ますが、登録しない場合、PCにログインするたびにこの画面が表示されるので、半強制的にPIN/生体情報を登録させることができます。

Windows Hello for Businsssのセキュリティ

もう一つのメリットとして、Windows Hello for Businessではクライアント⇔サーバー間の通信がPKI(公開鍵基盤)のロジックに変わります。

説明しますと、普通のWindows Helloでは、PCログイン時にPIN/生体認証を使用してログインするものの、その後は、PC内に保存されているパスワードハッシュをADに向かって投げつけるので、ログオンの瞬間以外は普通のパスワードログインと変わりません。

f:id:teraco:20171229143304j:plain

一方、Windows Hello for BusinessはクライアントPC ⇔ ドメインコントローラー(あるいはAzureAD)間の認証が、公開鍵基盤認証の仕組みで認証されるようになります。クライアントPC視点でドメインコントローラー(あるいはAzureAD)が認証局として動作します(するようです)。よって途中のパケットをキャプチャされても、もちろんパスワードは分かりませんし、公開鍵基盤認証の仕組み上、成りすましログインも出来ません。

f:id:teraco:20171229152247j:plain

すごい!!!!!!!

…しかし、この説明を聞いて「うお~すげ~!Windows Hello for Business導入するしかね~!」と思った人はどれくらいいるでしょうか?

MS側は”Windows Hello for Businessの一番のメリットはセキュリティだ!”とか言ってるのですが「パスワードハッシュが社内ネットワークを流れてるの、前々から問題だと思ってたんだよね~」という意識高い情シス担当者は少ないので、実際にこの点をメリットとして宣伝するのは、かえって混乱を招くんじゃないかな…と思います。現場の情シスさん、そんな高度な問題より、付箋にパスワードを書くようなユーザーに悩んでると思うんですよね。しかも、Windows Hello for Businessを構成後も、PCの内部にNTLMハッシュを持つので、Pass-the-Hash攻撃などは普通にやられるようです。

f:id:teraco:20171229144336j:plain

ひとまず、このエントリに限っては、パスワードハッシュがネットワークを流れずセキュア、というのは忘れてもらってよいかなと思います。一方Windows Hello for Businessは公開鍵基盤認証であるというのは、覚えておいてください。

Windows Hello for Businsss:よくありそうな質問

  • Q:Windows Hello for Businessを展開すればユーザーにパスワードを教えなくてもいい?
    • A:×誤りです。初回セットアップ時にADのユーザー名/パスワードが必要です。
  • Q:Windows Hello for Businessを展開すればPass the Hash攻撃されても大丈夫?
    • A:×誤りです。端末にパスワード情報が保存されるので、盗まれます。
  • Q:Windows Hello for Businessを展開すればネットワークにパスワードハッシュが流れない?
    • A:×誤りです。サーバーにNTLM認証を求められた場合、キャッシュされたパスワードハッシュを提供します。
  • Q:PINでのログインを禁止して、生体情報だけを許可する事は出来ないの?
    • A:×出来ないようです。システム的にはPINも生体情報も同じくらいセキュアと扱われています。

Windows Hello for Business ハイブリッド構成のパターン

さて、Windows Hello for Business ハイブリッドを構成するわけですが、4つの構成方法が提示されています。

Windows Hello for Business (Windows 10) | Microsoft Docs

  • Key trust Group Policy managed
  • Certificate trust Mixed managed
  • Key trust Modern managed
  • Certificate trust Modern managed

判断ポイントは2ポイントで

  • キー信頼モデルか、証明書信頼モデルか
  • グループポリシーでの管理か、Intuneポリシーでの管理か

です。今回はPOCだったので管理手法は別として、キー信頼モデルか、証明書信頼モデルかを検討しました。結論としては、両者に性能的な違いはなく導入する環境や使用予定のコンポーネントによって構成を決定すればよいとドキュメントに書いてあったので、比較的構築が楽なキー信頼モデルを採用しました。

Windows Hello for Business ハイブリッド キー信頼構成の構築手順

以下のマニュアルを見ながら構築しました。11/5時点では全て英語となります。証明書信頼モデルのマニュアルは日本語なのに…。

Hybrid Key Trust Deployment (Windows Hello for Business) | Microsoft Docs

簡単に手順を書きますと

  1. Hybrid Azure AD Join環境の構築
  2. 証明書テンプレートの入れ替え、KeyAdminの同期
  3. 各種ポリシーの設定

の3段階に分かれるかな、と思います。時間がかかるのはHybrid Azure AD Join環境の構築かと思いますが、こちらは割と世の中にナレッジがあるのでいけるんじゃないでしょうか。証明書テンプレートの入れ替え移行は手順通りに進めました。あまりやったことがない手順なのでビビりながら。

なぜWindows Hello for Business ハイブリッドでAzure AD Join端末からオンプレADにSSOできるのか

システム構成図はこんな感じです。

f:id:teraco:20171229153606j:plain

Windows Hello for Business ハイブリッドの手順の一環で、Hybrid Azure AD Join デバイス構成を構築します。

How to configure hybrid Azure Active Directory joined devices | Microsoft Docs

この構成では、Azure AD JoinしたWindowsPCの情報がオンプレミスのActive Directoryにコピーされます。具体的には以下のPC02です。

f:id:teraco:20171229155107j:plain

さて、Windows Hello for Businessは公開鍵証明書基盤の仕組みを利用して認証を行います。PC端末とAzure ADがクライアントと認証局の関係となり公開鍵証明書基盤方式で鍵をやり取り。最終的にクライアントPCが認証局から発行された認証トークン(?)をPC内部に持つと思われます。

仮のこのPCがオンプレミスのADに参加していた場合、Azure AD Joinした場合と同じデバイス情報がオンプレミスのADに作成されると思われます(これ、確認したい)。そしてオンプレミスADと公開鍵証明書基盤方式で鍵をやり取りし、最終的にクライアントPCが認証局から発行された認証トークンは、Azure AD Joinした時に発行されるものと同一となります。

f:id:teraco:20171229155443j:plain

以上より、Azure ADから発行された認証トークンを持ってオンプレADにログインしようとした場合、その認証トークンはオンプレADでも使えるものなので、オンプレADにシングルサインオンが可能となります。オンプレミスのActive DirectoryクラウドのAzure ADが同一の認証局となることで、クライアントPCがAzureADからもらった認証トークンはオンプレADでも使用できるものとなります。

…という理解です。恥ずかしながら上記動作はあくまで推測です。ネットワークキャプチャして通信暗号化解除して追えばわかると思いますが、そこまでの元気はありませんでした。。。

ただ、公式ドキュメントにAzure AD Joinしたデバイス情報がAADCでオンプレADにコピーされるまで、オンプレADへのSSOは出来ない、と書いてあるので、Hybrid Azure AD Joined構成でコピーされるオブジェクト情報が鍵を握っているのは間違いないと思います。実際、AADCでデバイス情報同期される前にオンプレADにアクセスした場合、シングルサインオンできなかったので。

ここらへん、ほんま自信なくてイベログにもそれっぽいログが出てなかったので、状況証拠からの推測でしかないんですよね…。ドヤったブログタイトルなのにすいません。

そして…課題

課題1. 初回ログイン後、一度サインオンすると、オンプレリソースへのシングルサインオンが出来ない。

なので使い物になりませんwww PCへの初回ログインや、別ユーザーで一度ログイン後、再ログインするとシングルサインオン出来るのですが…。これは僕の構成が間違っていたのか、そもそもバグなのか分かりません。初回ログイン時にシングルサインオン出来ているので、普通に考えると2回目以降もいけそうな気がするんですけどね。

おそらく、初回ログオン時はAzure ADからうまくトークン(?)を取れて、そこでオンプレリソースにSSO出来るのでしょうが、2回目以降のログインでは下手にPCのキャッシュを使ってWindowsにはログインできるが、PKI認証用の情報は消えてしまっている & 取得していないのでSSO出来ないのか、と思います。

課題2. オンプレADへのWindows Hello for Businessポリシーテンプレートが見つからない

本来的にはオンプレADにGPO適用し、オンプレADにデバイス登録されたPCにWindows Hello for businessを強制するようにポリシーを適用したかったのですが、テクサミ時点では管理ポリシーが見つからず、Azure AD Joinした端末にしかWindows Hello for businessを適用できませんでした。ここらへん、最近のyoutubeでは”オンプレもポリシー適用できるぜ!”って言ってるので、今は大丈夫かもしれません。

参考にした情報

docs.microsoft.com
www.youtube.com
channel9.msdn.com

www.slideshare.net

最後に

Windows Hello for Business ハイブリッドはまだ情報も少なく、本番導入時にどこでハマるか分からないので、新しい情報は積極的にキャッチしてアップデートしていけたらと思います。

Monthly Office 365 Update (11月分)

Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。めっちゃさぼってました。ひとまず11月分。

チェックソース

Office 365 メッセージセンター

MC124470 New feature: Microsoft Flow in OneDrive for Business

OneDrive for Businessのメニューの1つにFlowが表示されたよ、って話。前々からFlowでOneDrive for Businessは使えましたがFlowの画面から設定する必要があった。これからはOneDrive for Businessから設定できるが、情シス視点ではユーザーからの問い合わせに答えなければならず、大変そうですね。

MC124493 New Feature: Idle Session Timeout Preview Available in SharePoint Online and OneDrive for Business

10月の更新で言及された”MC117085 Changes to the Token Lifetime Default in Azure Active Directory“(Monthly Office 365 Update (10月分))とは別に、SPO,OD4Bでセッションタイムアウトが管理者側で決められるらしい。しかしながらこれについて説明された文章(Introducing Idle Session Timeout in SharePoint and OneDrive (Preview) – Microsoft Tech Community)を見ると、ユーザーがセッション保持を継続するオプションを選択すれば二度目は聞かれない、という事が書いてあるようにみえ、セキュリティ強化には繋がらないのでは、と思いました。

※ 本当にセキュリティ強化したいなら、一定時間毎にパスワードを入れ直す、などが必要。

MC124939 New feature: Message Center major updates

メッセージセンターで重要なお知らせのクローズアップやメールでの通知が実装できるようになったよ、という話。これはだいぶ前から展開が開始され、100%のテナントに展開が終了したとの事。次は前々から予告されているVIPユーザー監視機能のリリースをおなしゃす…。

MC125028 New feature: Compliance Manager public preview

コンプライアンス マネージャー管理画面のプレビューです。これ系のポータルではセキュリティ/コンプライアンスセンターがありますが、別物です。テクサミ感想のGDPRセッションに書いたけど、GDPR対応のためにMSではソフトウェアベンダーとして出来る限りの対応をする、と表明されており、このコンプライアンス マネージャーを使えば、自組織のOffice 365がどれだけGDPRに順守しているか(EUから刺されないように対応しているか)分かります、との事。

指標としては、既存のセキュリティ/コンプライアンスセンターのように各規格(GDPRはもちろん、その他国際規格)に対する”スコア”と”スコアを上げるための対策”が表示されるものとなってます。

ただ…。GDPRに関してはどういう条件でEUに刺されるかがまだ未定。なぜならGDPR運用開始が2018年5月だから。そこでMSは「E5ライセンスでSPOなどのデータにラベリングしてDLPで監査すれば情報管理してるって言い張れます!」ってアピールしてるんだけど…。これでEUに刺されないかどうかは誰も知らない。

MC125181 Updated Feature: New sharing tab in OneDrive for Business Admin center

Onedrive for Business管理センターの共有設定が分かりやすくなったよ、という話。確かに分かりやすくなってました。できる事は前と変わってません。

MC125218 New Feature: Focused Inbox

優先受信トレイがほとんどのテナントで有効になったよ、という話。無効にする方法はこちら。

組織内のすべてのユーザー用に優先受信トレイを構成する – Office 365

MC125489 New features: OneDrive for Business for iOS

OneDrive for BusinessのiOSアプリが新しくなるよ、という話。D&Dが可能になる、iOSのファイルアプリがサポートされる、130種類ほどのファイルがOneDriveアプリ内でプレビュー可能になる、など。IntuneのMAMについても動作確認済みなので安心。

追加費用なしでアクセス制御を実現できる、Exchange Online条件付きアクセス

Office 365 Advent Calendar 2017 – Adventarの7日目です。予定ではExchange Onlineの予定表機能について一言物申そうと思ってましたが、タイムリーにExchange Onlineの新機能が実装されたので嬉しくてテーマ変更します。嬉しい!

Exchange Online 条件付きアクセスとは

MC124248 New feature: Client Access Rules for Exchange Onlineで予告されていたExchange Onlineの新機能です。Azure AD Premium,EM+Sなどの追加ライセンスなしに、Exchange Onlineの設定だけでクライアントからの接続を絞る条件付きアクセスが実現できます。すごいぜ!!!!

Exchange Online のクライアント アクセス規則: Exchange Online Help

できること

以下の条件を組み合わせて、合致した場合に”アクセス許可”または”アクセス禁止”を設定できます。

  • ネットワーク
    • 単体IP:192.168.1.1.
    • IPレンジ:192.168.0.1-192.168.0.254.
    • CIDR形式:192.168.3.1/24.
  • アクセス手法
    • ActiveSync:ExchangeActiveSync
    • Exchange管理センター:ExchangeAdminCenter
    • EWS:ExchangeWebServices
    • IMAP4:IMAP4
    • オフラインアドレス帳:OfflineAddressBook
    • OutlookAnywhere:OutlookAnywhere
    • OWA:OutlookWebApp
    • POP:POP3
    • PowerShellWebServices:PowerShellWebServices
    • Exchange Online PowerShell:RemotePowerShell
    • RESTAPI:REST
  • 認証方式
    • ADFS認証:AdfsAuthentication
    • ベーシック認証:BasicAuthentication
    • 証明書認証:CertificateBasedAuthentication
    • 非ベーシック認証:NonBasicAuthentication
    • Oauth認証:OAuthAuthentication
  • ユーザー属性
    • ユーザー名
    • City
    • Company
    • CountryOrRegion
    • CustomAttribute1-15
    • Department
    • Office
    • PostalCode
    • StateOrProvince
    • StreetAddress

ユーザー属性については、ユーザー名は文字列指定(*によるワイルドカード指定可能、複数指定可能)、その他はOPath形式での指定となります。

やってみる

よくありそうな社外からのOWA使用禁止をやってみました。

1. ルール設定

会社のIPが 163.49.213.44 って想定でルールを作ります。プロトコル指定はOWAで、163.49.213.44以外のネットワークからはDenyとします。

New-ClientAccessRule -Name "BlockOWA" -Action DenyAccess -AnyOfProtocols OutlookWebApp -ExceptAnyOfClientIPAddressesOrRanges 163.49.213.44

ゲットするとこんな感じです。

PS C:\Script> Get-ClientAccessRule | fl
RunspaceId                           : 96ccb8b3-bf62-4c77-8850-c84bc4369e8b
Priority                             : 1
Enabled                              : True
DatacenterAdminsOnly                 : False
Action                               : DenyAccess
AnyOfClientIPAddressesOrRanges       : {}
ExceptAnyOfClientIPAddressesOrRanges : {163.49.213.44}
AnyOfSourceTcpPortNumbers            : {}
ExceptAnyOfSourceTcpPortNumbers      : {}
UsernameMatchesAnyOfPatterns         : {}
ExceptUsernameMatchesAnyOfPatterns   : {}
UserIsMemberOf                       : {}
ExceptUserIsMemberOf                 : {}
AnyOfAuthenticationTypes             : {}
ExceptAnyOfAuthenticationTypes       : {}
AnyOfProtocols                       : {OutlookWebApp}
ExceptAnyOfProtocols                 : {}
UserRecipientFilter                  :
Scope                                : All
AdminDisplayName                     :
ExchangeVersion                      : 0.20 (15.0.0.0)
Name                                 : BlockOWA
DistinguishedName                    : CN=BlockOWA,CN=Client Access Rules,CN=Configuration,CN=myalmea.onmicrosoft.com,CN=ConfigurationUnits,DC=JPNPR01A004,DC=PROD,DC=OUTLOO
K,DC=COM
Identity                             : BlockOWA
Guid                                 : 0ae9e5ce-6edb-48e6-bdf8-76d23d08135e
ObjectCategory                       : JPNPR01A004.PROD.OUTLOOK.COM/Configuration/Schema/ms-Exch-Client-Access-Rule
ObjectClass                          : {top, msExchClientAccessRule}
WhenChanged                          : 2017/12/07 23:32:39
WhenCreated                          : 2017/12/07 23:32:39
WhenChangedUTC                       : 2017/12/07 14:32:39
WhenCreatedUTC                       : 2017/12/07 14:32:39
Id                                   : BlockOWA
OriginatingServer                    : KAWPR01A004DC01.JPNPR01A004.PROD.OUTLOOK.COM
IsValid                              : True
ObjectState                          : Changed

2. 動作確認

もちろん実機からも動作確認するんですけど、めっちゃ優れものだな~と思うのは、Test-ClientAccessRuleってコマンドでどのルールが適用されるかシミュレーションできるんですね。(オンプレADのポリシーの結果セット的なやつ)

Test-ClientAccessRule -AuthenticationType BasicAuthentication -Protocol OutlookWebApp -RemoteAddress 163.49.213.44 -RemotePort 443 -User admin@almea.jp
Test-ClientAccessRule -AuthenticationType BasicAuthentication -Protocol OutlookWebApp -RemoteAddress 163.49.213.45 -RemotePort 443 -User admin@almea.jp
Identity Name     Action
-------- ----     ------
BlockOWA BlockOWA DenyAccess

1行目は許可したいIPからアクセスしている想定なのでルールがヒットしませんが、2行目は許可IPじゃないので、Denyのルールにヒットしてます。これで許可と拒否ルール間違えて実装とかしても気づくね!

ちなみに最初のルール設定時に”最長24時間かかる事があるよ”って言われて、まっさか~って思ってたらマジで12時間くらいかかったので気長に待ちましょう。2回目からは1時間以内に反映されるようです。

実機からは以下のような画面でブロックされます。

f:id:teraco:20171207235546p:plain

これでAzure AD Premium, EM+S不要じゃない?

一応、EM+Sとの違いをまとめておきますと。

Exchange Online条件付きアクセス EM+S条件付きアクセス
対象 Exchange Online Office 365,Azure AD 連携アプリ
条件 IP、クライアント種別、認証方式、ユーザー IP、ブラウザまたはアプリ、ユーザー、バイス
アクション 許可、拒否 許可、拒否、二要素目を求める

バイス情報での制御、条件に合致したら電話番号などで二要素認証したいならEM+S。逆にExchange OnlineはpowershellREST APIなど細かい制御が出来るのはよいかも。管理用端末からはpowershellでしかアクセスさせない、とか。

なお、EM+Sの条件付きアクセスと違って、Exchange Online条件付きアクセスでOWAアクセス禁止しても、Teamsその他にはふつーにログインできます。不思議だわ~。

※ EM+S条件付きアクセスでExchange Onlineへのアクセスを禁止すると、Exchange Onlineを基盤としているTeamsへのアクセスも禁止されてしまう

Tips

Exchange Online条件付きアクセスはルールに優先度がつけられ、優先度の高い方から合致したルールが有効になるようです。てことで、管理者IDについてはpowershellを常時許可、みたいなルールを優先度0に入れておくと安全だな、と思いました。

ということで

Exchange Online導入したいけど、ネットカフェからはアクセスさせたくない、ちゃんとVPN張ってアクセスさせたい、というエンタープライズ用途には朗報なんじゃないでしょうか。Exchange Onlineについては、既定の機能でユーザー毎にIMAPやPOPの許可/不許可もコントロールできましたが、Exchange Online条件付きアクセスで一括でポリシーを設定できるのも運用上楽になるかと思います。

逆に言うと、EM+S買ってIP制限しかしない、とかヌルいことやってないで、もっとリッチな機能使おうよ、ってメッセージなんでしょうか。

明日、12/8は@hrfmjpさんです。お楽しみに!

(メモ)PowerShellでSharepoint Online のリストライブラリの分析

Sharepoint Online のリストライブラリの分析をしようと思い、PowerShellでさくっと出来るやろ~と取り掛かったのであった。ググったところ、ドンピシャのエントリが発見できたので…

PowerShell で、SharePoint Online の リストとアイテムの情報を書き出してみた – Qiita

このままコピペ→動作確認完了!後は取りたい列を追加してcsvに吐き出せば終わりやで~ → (To上司)もう取れたも同然です。

SharePoint の列名の取得

上記から1週間後、さくっと列名取得しますか…と思い、 $item | fl で属性全出しを試した所…エラーが(´・ω・`)

コレクションからの列挙中にエラーが発生しました: The collection has not been initialized. It has not been requested or the request has not been executed. It may need to be explicitly requested.。

困ったときはget-member, get-type, flで力押しってExchange Onlineで習ったのに…!!!!

さすがに列名全出しする方法あるやろ…と予想しネットでググるも、記事が見つかるがコマンドが通らない。まさか、オンプレ専用コマンド!?

結局、列名のオリジナルを取得する方法を調べる方向に舵を取り、無事に狙った列名を指定してpowershellでアクセス出来たのでした。

本題

本当はpowershellをAzure Functionで動かしたいんですってことでメモ。今回、サンプルスクリプトで.Netのアセンブリ使っているので、これをAzure Functionにアップロードしなければいけない。その方法はこちら。

Azure Functions: PowerShell Script Interacting with SharePoint Online – Stack Overflow

モジュール配置方法を調べる & 上記の列名特定方法を調べている途中で、”こういうめんどくさいことから解放されるためにGraphAPI使えばええやん”と思いつき、ちょっとだけ触ってみました。Exchange OnlineのGraphAPIは触ったことあるけど、さすがにSPOもあるのね。

ただ、意図した通りには動いてくれず。そこまで深堀しておらず、僕のSPO経験値が少ないからかもしれないので。Channel 9 の動画を見つけたので、時間がある時に見ることにします。

Microsoft Tech Summit 2017の感想など

行ってきました。

Microsoft Tech Summit 2017 | インフラエンジニア、アーキテクト、IT 戦略立案に関わる皆様の為の技術カンファレンス – Microsoft Events & Seminars

場所はウェスティンホテル東京で写真はこんな感じです。写真の腕がしょぼくてすいません。

f:id:teraco:20171109231043j:plain

f:id:teraco:20171108114243j:plain

少し宣伝

今回は、自社のブース展示&対応を行っていました。内容はAzure AD JoinしたWindows 10 PCで、オンプレADにSSOできるというものです。今まで、オンプレADにSSO出来るのはそのADに参加している端末のみ、ワークグループ端末その他は、オンプレファイルサーバーなどにアクセスする際、ID/Passwordを入力するのが常識です。しかしながら、ある条件、具体的にはWindows Hello for Business ハイブリッド構成環境であれば、Azure AD JoinしたPCでオンプレADにシングルサインオンできちゃうんです!!!!すごい!!!!

…というのがあまり実感頂けなかった気がするので、ロジックなどを別のブログ記事で説明したいと思います。ひとまず検索で引っかかるようにキーワードを強調表示しておきます。。。

宣伝はこれくらいにしてセッションの感想です。展示準備のため十分に参加できませんでしたが、聞けたところだけメモします。

DAY1:CLD001:インフラ エンジニアにもできる企業の IT 改革 ~モダンなインフラを作ろう~

途中から入室。少し抽象的なセッションで、意気込み重視というか、技術的な要素は少なかった気がします。

DAY1:PRD012:16万人の「働き方改革」を支えるICT活用 ~社内実践から見えた効果と課題とは~

富士通さんのセッション。使用されている技術に目新しさはないけど、それをどうやって16万人に浸透させるか、という話。新しい技術を振りかざしてお客様を訪問するだけではなく、その技術を実際ユーザーにどうやって使ってもらうかまで意識しないといけないな~と思いました。。新システム導入で一番怖いのは、使い勝手が悪くてユーザーから文句が出るのではなく、導入しても無視され使われない事なんです。

DAY1:SEC001:GDPRと国境無きインターネット

お仕事に影響あるのでちゃんと聞きました。

GDPRという制度について

  • EU域内の国民の個人データを他の国で不適切(適切であっても?)に保管すると罰金。売り上げの4%か26億円。
  • EUは本当に制裁を発動させるので、ちゃんと対応する必要がある。
  • 何かいちゃもんつけられた時に、少なくとも”ちゃんとやってますよ”と説明責任を果たす必要がある。

個人データとは?

  • メールアドレスも個人データ。
  • メールリレーサーバーをメールが通っただけでGDPR対象。個人データの処理が対象だから。
  • IPアドレスcookieも個人情報である。
  • つまりなんでも個人データと思った方がよい

GDRPの登場人物

  • データ主体⇔管理者⇔処理者
    • データ主体:個人(EUの人たち)
    • 管理者:お客様企業
    • 処理者:MS(SaaS事業者)
  • Q.日本にしか会社ないんだけど?
  • A.日本にしかなくても、EUの人がショッピングサイト使って自分の名前などを登録しており、ショッピングサイトが日本にあればGDPR対象

GDPR有効化における主要な変更点

  • データ主体者の権利を担保する
    • アクセス
    • 修正
    • 消去
    • 意義申し立て
    • エクスポート
  • 制御と通知を確保する
    • データに対するセキュリティ
    • 侵害検出後の72時間以内の当局への通知
    • 同意の取得
    • データ処理の詳細な記録の保持
  • EUのデータを収集するのがダメなのではなく、きちんと管理してますよ、と言えない事が問題である。
  • DPO(Data ProtectionOfficerの選出)はほぼ必須

※ ここらへん、後でスライド補足

EU域外+信頼されている国以外にデータを出すのは原則禁止。EU域外で”信頼されている”国は10数か国で日本は含まれない。

マイクロソフトはどうやってるの?

“世界中のお客様のGDPRへの取り組みをお手伝いします。”具体的なアクションはオンラインサービス条件の中に文言として盛り込む。ひとまず安心してほしい。

…とのこと。

具体的なシステム面からの説明はありませんでしたが、SaaS事業者としては、EUリージョンに建てたIaaSを勝手に他のリージョンに移動しない、という事になるのでしょうか。このセッションを聞いていると、GDPRはSaaS事業者だけの問題ではなく、SaaSを使用する企業自身の問題と感じました。

お客様は何をしないといけないのか??

“ちゃんとやってますよ”というプロセスを作る。例えば、名刺を受領した時…

  • ×よくない例
    • 各人の名刺入れに保管し、捨てたり家に持ち帰ったりポリシーが統一されておらず、トラッキングは出来ない。
  • ○よい例
    • 社内に持ち帰った段階で、名刺管理DBに情報を入れている
    • 各人は必要な時にオンラインで名刺管理DBを参照する
    • 名刺管理DBはIRMがかかっており、社外にコピーできない

など。

感想

EU国民のデータを日本のサーバーで触らない、となると、自社のお問い合わせフォーム用のサーバーをEUに配置して、EU域内のIPからアクセスされた場合、EU内のWebフロントエンドに飛ばしてデータもそこで持つ…としないといけないけど、どんだけシステムコストかかるねん、という話だし、例えばEU国民が日本に旅行に来て日本語でお問い合わせフォームに書いたら、システム上はGDPR対象のデータであると分からない。

それ以前に、仮にEUにEU国民のデータを保管しても、日本の端末から閲覧しただけでブラウザキャッシュが残っちゃうので、結論から言うとシステム的にGDRPを守るのは不可能じゃないかと。

よって落としどころとしては、EU国民のデータも”仕方なく”日本国内のサーバーで処理しちゃうことがあるけど、ちゃ~んと保護するし、ユーザーから申請があれば削除するようなフローを作るし、不要に長期保管しない仕組みを作ってますよ、と言うしかない?

まーしかしskype会議でEUの支店と会話してPPT共有したらどうすんねん、とか考えると辛いね。GDPRの正式施行は2018年5月らしいので、EUの動向に要注目です。

DAY1:SEC002:セキュリティ マニアックスでおます~コネクテッド カー時代に活かす IT サイバー セキュリティ~

途中入室。面白かった~。

  • クルマのハッキングを防御するためには、PCと同じく多層防御の考え方が必要。
  • PCの場合
    • Tier2:クライアントPC
    • Tier1:管理者アカウント
    • Tier0:サーバー
  • のような多層構造となっており、クライアントPCがやられてもそいつを組織から切り離せばOK、など。
  • クルマの場合
    • Tier2:物理ソケット。ここが破られるとチップを入れ替えられて物理的に乗っ取られてしまう。例えばカーシェアなど不特定多数で共有する車はこういった物理的なセキュリティもしっかりしているべき。
    • Tier1:インフォなんとか(名前忘れた):エンタメ系のモジュール。外部との通信のためにポートが空いていると危険
    • Tier0:駆動系モジュール(名前忘れた):車に”前進”や”後退”の信号を送るモジュール。本当はここをしっかり守りたいが、このモジュールはCPU性能が低くふるまい検知やアンチウイルスを動かすことが出来ないので、現状、Tier1までで防御する事が重要

クルマ業界も何もやっていないわけではないが、ファームウェアを書き換えられるなどは想定しておらず、IT業界では当然の対策がされていない部分もある。昔からハックに対応してきたIT業界の知見が必要である。

DAY1:SEC005:ネットワーク エンジニア必見!VPN/DMZ は要らなくなる!? Azure AD Application Proxy で実現するセキュアなアクセス

ネットワークエンジニア向け…なのか?前半、Azure APP Proxyの構築方法。VPNと違って外→内の通信がないからセキュア。内→外の通信。構築時に認証付きプロキシは回避してね。オンプレアプリはAzureポータルからエンタープライズアプリケーションを追加する。理解しやすかったが、レベル400もあるかな…と思いました。

以上がday1。終わった後はBeerBush。写真撮り忘れた…ローストビーフ美味しかったです。

DAY2:DEP008:Microsoft System Centerによる進化したハイブリッドクラウドの環境の管理

System Center RunbookをAzure automationに移行できる、など。個人的にSCCMとIntuneの連携を聞きたくて参加したけどあまり話題なく。System CenterってSCCM以外の機能がたくさんあったの忘れてた僕が悪いですすいません。

DAY2:CLD012:百聞は一見に如かず。デモで理解する Azure Stack の面白さ!

今回のTechSummitの目玉はAzure Stack、ってくらい注目度が高く、セッションも多かったです。このセッションでは利用者からみたAzure Stackと管理者からみたAzure Stackを説明し、最後にAzure Stackのマルチノードの動いている所のデモでした。マルチノードすごい。

事前にちょいと勉強したのですが、Azure Stackって、本当にAzureがオンプレでそのまま使える、以上終了、みたいな所ありますよね。もちろん、負荷分散やネットワーク、冗長化などの構成を考える必要はありますが、それは考えればいいだけで、使う側の使い勝手は変わらない。

ということで、決め手はAzure Stackの使いどころをどのように提案できるか、だと思いました。なんとなく、他のソリューションに比べて営業サイドの人たちが使い方提案で売り込む、Surface HUB的な製品なのかな…と勝手に思ってます。

DAY2:DAL005:Azure Cosmos DB を使った高速分散アプリケーションの設計パターン

同時間帯のハンズオン満席だったのでこちらのセッションに参加。思った以上に面白かったです!CosmosDBは早いしDR組みやすいしよい!けど高いから既存のSQLと役割分担するとよいよ。デモでは軽~く使ってたけど、ドキュメントまじめに読むと1か月かかると言われてビビってます。説明のペースが速かったのでPPTで復習したいと思います。

DAY2:SEC009:Azure AD による Web API の 保護 ~ Azure API Management をセキュリティの観点で解説

Webアプリを使ってAPIを実装し、そのAPIを開発者やユーザーに開放する時に、APIを適切に管理する方法。Azure ADや!って同僚のインフラエンジニアと参加したのですが「そもそも俺たちWebアプリ作ったことある?」とのっけから脱落気味。便利さは一応理解したものの、ちょっと我々には早すぎた…か。ただ、このご時世、アプリ作ったらAPI公開して当然という気もするし、NAVITIMEや駅探のAPIは便利に使わせてもらってます。こういうのをAzure AD基盤で管理できるは知らなかったので勉強になりました。

DAY2:APP003:Azure Functions と Serverless – 概要と企業向け Tips

この時間帯、見たいセッション被ってたんですよね~。Cosmos DBで興味が出たのでAzure Functionへ。これ、全然マークしてなかった自分が恥ずかしく。基本的なサービスのトリガーとバインディングも用意されているから、今までサーバーにスクリプト置いてタスクスケジューラーで動かすシステムを捨てることが出来る。Automationは少し触った事があったのですが、Functionはそれより簡単にデプロイできてびっくりしました。インフラ関係の仕事だと使う機会少なそうだけど、何かの案件で無理やり使ってみたいな~。

DAY2:SEC007:Azure AD B2C と LINE 連携により実現する学校や企業における次世代 ID/メッセージ基盤

期待していただけあってディープでした…。SNSのIDと連携できるAzure AD B2Cだが、標準で連携できるサービスにLINEが入っていない。ならカスタムで作っちゃおう、との事でしたが、ドキュメントがないためほぼ手探り。そりゃ社外秘だわな…。面白いセッションだったけど、これを聞いて”参考になった!自分も解析しよう!”となる人はどれだけいるのか…。なんとも圧倒されるセッションでした。

感想

去年のメモを見返していたのですが。

Microsoft Tech Summit 2016に行ってきたメモ – 今日も元気にIT屋さん

  • 今年増えたもの
    • Azure Stack
    • IoT
    • Serverless
  • 今年減ったもの
    • Exchange/skype
    • MS365製品の単品セッション
    • ID統合系(AADC同期パターンだけの話)
  • 変わらないもの
    • EM+S(ADFSもういらない系の話)

※ あくまで私視点です

個人的にはTeamsがないことが意外でした。EM+S系、Microsoft365系は、おそらく知ってる話だろうな~って出なかったんですがtwitter追ってる感じだと多分予想は当たってたのかな、と。EM+Sの条件付きアクセスについては去年の時点で概念自体は完成していた気もしますが、自分が自社ブースでデモ手伝ってる中でも、まだまだエンドユーザーの情シスまでは浸透していないのかな~?と感じました。キャズム超えそうな雰囲気はあると思うのですが、まだ啓蒙活動が必要だと思います。他は、やはりOffice 365って名前付くとセッション参加人数増えるんだろうけど、Microsoftさんとしてはそういうベーシックなんじゃなく、他の技術をアピールしたいんだろうな~って思ったりしました。