MicrosoftTeamsの既読通知機能を有効にすべきかどうか問題(通知機能の選択)

今までのエントリ

現状のまとめ

対象 既読通知機能 既読表示タイプ
チームチャット ○有効(有効/無効/ユーザー選択可能から選択可) 不明
プライベートチャット ○有効(変更不可) 不明
  • チームチャット、プライベートチャットとも既読機能が有効になる
  • 既読表示タイプは以下の2タイプがあるが、どちらが実装されるかは不明
    • タイプ1. 読んだ人数が分かるが、ユーザーは分からない
    • タイプ2. 人数も、ユーザーも分かる

機能利用の選択

プライベートチャットは強制的に既読が有効になるため、チームチャットの既読動作について選択できる。選択肢は以下の5択。

既読通知機能 既読表示タイプ
有効 タイプ1. 人数しか分からない
有効 タイプ2. 人数も、ユーザーも分かる
ユーザー選択可能 タイプ1. 人数しか分からない
ユーザー選択可能 タイプ2. 人数も、ユーザーも分かる
無効 なし

ここでまずユーザー選択可能は選んではいけない事を主張したいです。前のエントリで

  • 既読機能に対して、違った解釈が発生するのはリスク
  • 既読機能の使い方はルールを決めてつかうべき

と書いた通り、チームによって既読がつく/つかないが変わる場合、組織全体として統一された動作にならず、ルールも文化も統一されないからです。

つまり事実上の選択肢は以下3つ。タイプ1かタイプ2かはマイクロソフト社の実装によるので、こちらに選べるのは有効か無効かだけですね。

既読通知機能 既読表示タイプ
有効 タイプ1. 人数しか分からない
有効 タイプ2. 人数も、ユーザーも分かる
無効 なし

プライベートチャットと組み合わせるとこんな感じかな?

パターン プライベートチャットの既読通知機能 チームチャット既読通知機能
1-1 ○有効 ○有効(タイプ1. 人数しか分からない)
1-2 ○有効 ○有効(タイプ2. 人数も、ユーザーも分かる)
2 ○有効 ×無効

それぞれについて評価してみます。

パターン1-1. プライベートチャット(○有効) / チームチャット(タイプ1. 人数しか分からない))

この場合ですが、実質パターン2みたいなものじゃない?と思います。なぜなら10人程度のチームで5人が既読をつけても、誰が既読したかが分からないので何も判断できない。そして、一般的にチャットと違ってチームは多数のユーザーが所属するものであり、全体のユーザーと比較してアクティブなユーザーは少ない。

ひとまずプロジェクトに関わりそうな人をチームに追加したが、今アクティブなのはシステム構築メンバーのみ、のようなパターンだと、40人中7人が既読、33人が未読、みたいな状態がありうる。

なので、チームチャットがLINE型で実装された場合は、チームチャットをオンにするメリットはないため、オフにするのがよいと思います。

(もちろん、組織内のユーザーが少なく、チームのユーザー数 = アクティブユーザー数な会社はそうではありませんが)

パターン1-2. プライベートチャット(○有効) / チームチャット(○有効(タイプ2. 人数も、ユーザーも分かる))

一番シンプルな形。ユーザーの混乱は少ないですが、チャットもチャネルも既読が有効になって息苦しいかもしれません。Teamsの動作は統一されますが「Teamsは既読機能が有効になってて嫌だ!」という理由でメールが使われ続けるリスクもあり…。

パターン2. プライベートチャット(○有効) / チームチャット(×無効)

プライベートチャットは既読が有効だが、チームチャットは無効な構成。パターン1-2ほどシンプルではないですが、混乱する設計ではないと考えます。チームチャットの既読機能が無効なため、平穏に過ごせます。外部ユーザーをチームに招待しているパターンなどは、この構成がいいかもしれないですね。

欠点は、プライベートチャットがチームチャットの上位機能になってしまうため「チームチャット使わずに、プライベートチャット使おうぜ!」勢が生まれそうなこと。これを欠点とするかは会社によりますが、仕事に関するコンテンツが個人ではなくチームに保管されるべき、という観点で、原則チームチャットでコミュニケーションするべきだと僕は考えています。

よってこの構成では

  • 仕事のコミュニケーションは原則チームチャット
  • プライベートチャットの使いどころは在籍確認や電話で不在だった時の伝言メモ程度
  • あるいは、仲のいい個人での業務外の会話程度

という文化の形成が大事かな、と思います。

ユースケース

最後に、ありそうなユースケースと利用例を考えました。

ケース1. 相手が自分のメッセージを読んだか、確実に確認したい

この場合はパターン1系の通り、チームチャットで既読機能を有効にするのがよいと思われます。しかしながらチームチャットの既読タイプが「タイプ1. 人数しか分からない」場合、誰が読んだか分からないのでこの目的は達成できないです。そもそも、このようなケースでは個人チャットでメッセージを送れば既読が有効なので、チームチャットの既読機能を有効にするまでもないかもしれません。

ケース2. 業務時間外にTeamsを読んでいる事を知られたくない

例えば、BYODの私用スマホにTeamsが入っていて、ついつい通知が気になって見てしまった、けど返信は会社でしたい場合。これは既読通知をオフにするのがいいですね。

ケース3. 社外にいるメンバーがちゃんと仕事をしているか確認したい

これをTeamsの既読機能で管理するのはナンセンスでしょう。既読をつけるだけならスマホからでも出来るし、逆に真剣に仕事する時はTeamsを見ずに集中するので、全く当てにならないと思います。

ケース4. メールよりも気軽なコミュニケーションツールとしてTeamsを使いたい

“気軽”の定義にもよりますが、既読機能が”気軽さ”の足かせになるなら無効にするべきでしょう。例えばメールに慣れた年配の方にTeamsを使ってもらう時に「既読通知があるから、返信するための時間を確保してからじゃないとメッセージを読まない」と敬遠されるのはもったいない事です。

ケース5. 既読だけついて返信がなければ”了解した”という文化を形成したい

なんか一見良さそうですが、メッセージの送り手が気を付けないと誤解が生まれそうです。例えば

6月10日は午前中外出します

のような単純な内容ならいいですが、

来週のミーティングの資料を××に保管したので、みなさん必要に応じて追記してください

のようなアクション内容があいまいなメッセージや

昨日購入した××社の製品ですが、かなり高性能で市場に受け入れられそうです。つきましては、どこか時間のある場所で説明させていただいたのち、××社にフィードバックを行いつつ、拡販を進めていこうと検討しております。

のような多様な内容が含まれるメッセージに対して、既読だけで理解の有無をジャッジするのは無理です。この場合、メッセージの送り手が、読み手に期待するアクションを指定する、例えば「問題ない場合は”いいね”をお願いします」や「賛同いただける場合はコメントで候補日時をください」などとする必要があります。

やはりコミュニケーション能力が高い、あるいはチャットコミュニケーションに慣れているメンバーが多くないと、既読機能を使いこなすのは難しいのでは?と思いました。

MicrosoftTeamsの既読通知機能を有効にすべきかどうか問題

現状のまとめ

対象 既読通知機能 既読表示タイプ
チームチャット ○有効(有効/無効/ユーザー選択可能から選択可) 不明
プライベートチャット ○有効(変更不可) 不明

※ 2019/5/23現在、既読機能は未実装ですが、予告されたロードマップから仕様を推測しています。

  • チームチャット、プライベートチャットとも既読機能が有効になる
  • 既読表示タイプは以下の2タイプがあるが、どちらが実装されるかは不明
    • タイプ1. 読んだ人数が分かるが、ユーザーは分からない
    • タイプ2. 人数も、ユーザーも分かる

詳しくは前エントリを参照

Teams以外のビジネスチャット開発会社のスタンス

考察にあたって、先行する各ビジネスチャットの既読機能の有無と主張を確認しました。ざっくりまとめると既読機能を肯定する内容は少なかったです。理由としてはいかが考えられます。

  • 既読機能がついていないビジネスチャットの方が多い事
    • 自社の製品を正当化するため、既読機能を否定
  • 一般論的に若年層に比べて年配層の方が既読機能に抵抗があるため
    • おそらく社外に公開する文章を書くのは年配層に近い人物であるため

既読機能は不要だよ派

チャットの「既読」が生む仕事のミス! | ビジネスチャット「知話輪」

「知話輪」に既読機能がないのは、「自分のメッセージを相手が読んだことがわかるので、安心する」というメリットに疑問があるからです。ビジネスコミュニケーションにおいて、「既読がついた」という事実だけで安心できるでしょうか。本当に重要なのは「伝わったかどうか」です。 私たちは、既読がつけばメッセージを読んでくれたと思いがちです。しかし、既読がつくことでわかるのは、「そのタイムラインを開いた」ということだけなのです。開いただけで、読んでいない場合でも既読がついてしまいます。 (中略)既読機能で得られるのは「自分は伝えた」という安心感のみです。しかし、本当に大切なのは「伝わる」ことです。

既読機能はありますか? – サポート | Chatwork

すぐに返事をすることがメインのコミュニケーションツールと違い、Chatworkは自分のタイミングでメッセージを確認できるツールです。

ビジネスチャットに既読は必要?今求められている機能とは

立場によってもプレッシャーの感じ方は様々で、上司と部下、取引先への返信など、既読をしているにもかかわらず返答が無いと相手に対して何らかの不快感を与えてしまう可能性が出てきますし、そういった不安を残したまま業務を行わなければいけません。

既読機能は必要だよ派

疲れないためのビジネスチャット運用のコツ – LINE WORKS

LINE WORKSは仕事用なので、業務連絡が誰に伝わったか、誰に伝わっていないかが分かるというのは、実は業務効率にすごく影響します。なぜかって、「了解です」という返事が来なくても、既読がついていれば「あ、この人は読んでくれた」とわかるから、送った方は「読みましたか?」って確認しなくて済むからです。

この機能を活用して、既読がついていれば、「了解です」の返事をしなくて良い、というルールで運用している企業、聞いてるとけっこう多いんです。

既読がつけば返事をしなくても良い、のメリットは2つあります。

一つは単純に返事をする手間が省けること。多忙な業務の合間に返信する手間がこれで省けます。

二つめは、これが実はけっこう重要なんですが、大人数のグループチャットで「了解です」の返信やスタンプを返すと、返事だけがひたすら連続するトークルームになってしまうんです。

その他

高校生のLINEでのやりとりに対する認知に現代青年の友人関係特徴が及ぼす影響

日本パーソナリティ心理学会の論文。高校生400名にアンケートを取ったところ、既読機能の存在により行動に制約を受け、ストレスとなることが有意に認められる。

LINEの「既読」機能はなぜ無くならないか | Books&Apps

かなり痛烈に既読機能を批判していますが、ロジカルだったため紹介。

本来、メッセージの処理は「受け手」に任されてきた。無視しようが、返事を返そうが、いつ反応しようがそれは、「メッセージを送る相手」に任されてきた。「返事を返さない、という返事」も選択肢として存在していた。

その権利を、LINEは取り上げたのだ。

「LINEはメッセージ送信者のワガママを叶えます!」

そういうことだ。

しかし、本来メッセージは「受け手」を中心に考えなければならないものである。コミュニケーションとはそういうものだ。

それを壊し、「メッセージの送り手」のワガママを助長する。LINEはますますコミュニケーションの下手な人を増やすことを助長していると私は思う。

ひとまずの結論

組織所属メンバーのコミュニケーション能力に自信がない場合、既読機能はONにしない方が良い

正直、今回いろんな記事を探すまではうまく既読機能を使えばコミュニケーションがよりスピーディーに、円滑に進むのではないかと思った。しかしながらそういったメリットよりも、既読機能のデメリットの方が大きく作用しそうに思えます。

リスク1:既読機能に対して、違った解釈が発生する

同じシステムでも、部署や事業所によって使い方が違う事はよくあります。文化の違うチームメンバーが混ざった場合「うちのチームでは”既読”がついたら”了解”のニュアンスだった。」「いや、うちのチームは”既読”は関係なく、明示的にレスポンスを返すルールだった。」など、混乱が発生する可能性があります。

リスク2:コミュニケーション下手なメンバーの存在

例えば、相手の事を考えずに話に割り込んでくる、いつでもすぐに電話をかけてくる、相手が納得したかを確認せず言いっぱなしでその場を去る、などコミュニケーション能力に問題がある人は既読機能をメッセージの送り側が都合の良いように解釈する可能性が高いと考えます。となると、既読機能反対派が懸念する問題が発生する可能性が高いと思われます。

以上の2つの理由より、ユーザー属性がばらばらである、あるいは組織規模が大きければ大きいほど(確率的にコミュニケーション下手なメンバーが存在する確率が高くなり)既読機能を使うのは難しい、と言えるのではないでしょうか。半面、スタートアップなど数人の会社なら、既読機能の解釈もブレにくいでしょう。

図にするとこんな感じでしょうか。

しかし既読機能をオフにしようとしても、個人チャットは強制的にオンになっちゃうぽいですし、困りますね…。

既読機能をうまく使える条件

条件1. 既読機能に対する解釈を組織内で統一できる事

例えば以下のようなルールを制定して、管理者が宣言する

  • 既読機能は相手に何らアクションを強制するものではない
    • 何かアクションを指定する場合は、メッセージ内にその旨を記載し、望むアクションを指定する事
  • 既読をつける行為は、相手に何かを自分の意思を伝えるものではない
    • 何らかの意思表示をする場合は、いいねやコメントをつける事

宣言するだけではなく徹底させなければいけないため、組織規模が大きいと大変そうです。

条件2. 既読機能を都合の良いように解釈するメンバーがいないこと

管理者が宣言したルールを破る人がいた場合、ルールを破られた周りのメンバーの不快感が非常に大きくなるため、既読機能の利用は停止したほうがいいでしょう。

ということで、次のエントリでは既読機能を使う前提として、Teamsでの既読機能の構成を考えていきます。

MicrosoftTeamsの既読通知機能を有効にすべきかどうか問題(用語の整理)

そもそも既読”通知”機能とは

メッセージを表示(=開封する/読む)すると、会話相手に分かるよう、通知が行われる機能です。代表的なものはLINE。そしてこの機能には2種類の表示タイプがあります。

タイプ1. 既読にした”人数”だけが分かるもの

例えばLINE。10人のLINEグループがあるとして、既読が5人になってもだれが既読になったか分かりません。


※ 画面ショットは8人のグループで7人が既読なので、みんな読んでいる事が分かります。

タイプ2. 既読にした”ユーザー名”まで分かるもの

ビジネスチャットによっては、既読した人がリストアップされるものもあります。例えばLINEWORK。

トークの既読確認 – LINE WORKS

上記ページから写真を引用させていただきます。

Teamsでは”いいね”がこのタイプですね。赤枠のように”いいね”した人が分かる。

MicrosoftTeamsの既読通知機能

MicrosoftTeams(以下Teams)の既読関連機能を整理します。なお、機能の中には未リリースのものもあるため、後で変わる可能性があります。

機能1. Teams管理画面から設定できる「開封確認」機能

この管理機能は現在動作しておらず、何を管理するものなのかは2019/5/23現在分かっていません。とはいえ、機能2を考えると、これはチームチャットの開封確認を管理するものと予想されます。

機能2. ロードマップでリリース予告されている「プライベートチャットの開封確認機能」

https://www.microsoft.com/ja-jp/microsoft-365/roadmap?filters=&searchterms=51552

全文を転載し、日本語訳も掲載します。

(原文)
Microsoft Team – Read Receipts in private chats

Increase communication transparency with Teams. Do you often wonder if your teammates saw your message? Read receipts in private chats allow senders to know when a message was read by the recipients.

(日本語訳)
Microsoftチーム – プライベートチャットで領収書を読む

チームとのコミュニケーションの透明性を高めます。あなたのチームメイトがあなたのメッセージを見たかどうか不思議に思いますか?プライベートチャットの開封確認メッセージを受信者が読んだときに送信者は知ることができます。

この機能は2019年6月にリリース予定で、現在開発中となります。(2019/5/23時点の情報)

まとめ

機能名 対象 既読通知機能 既読表示タイプ
機能1 チームチャット ○有効(有効/無効/ユーザー選択可能から選択可) 不明
機能2 プライベートチャット ○有効(変更不可) 不明

ここまでの推測より、チームチャットもプライベートチャットも、既読機能が有効になると思われます。そしてどちらの機能も、既読表示タイプは分かっていません。

既読”管理”機能との違い

Teamsでは、自分自身の管理のために、チャット・チャネルメッセージの未読・既読を切り替えることが出来る。一度読んだメッセージを”未読”に戻すと、画面のように未読状態となる。自分専用の”しおり”的な機能だと理解すると分かりやすいです。

本ブログの一覧の議論ではこの機能は扱いません。

IPアドレスが分かっている自社メールシステムからのメールをEOPでスパム判定されたくない

概要

以下のような構成の際に、自社メールシステムからのメールを確実にExchange Onlineで受信したい

構成1:自社メールシステム(IP特定可能)から、自社Office365へのメール送信

構成2:自社メールシステム(IP特定可能)から、自社Office365や他社へのメール送信

EOPの仕組み

ポイント

大別すると、EOPは以下の2つの観点でスパム判定を行っている。

観点1. メールの送信元

まず

  • 接続フィルター
  • Microsoftブロックリスト
  • Spamhaus

で、不正なIPからのメール送信ではないことを確認する。また、不正なIPからでなくても、短時間に大量のメールを送信するようなメール送信元はここでブロックされることもある。

観点2. メールの中身

送信元チェックを潜り抜けたメールは

  • マルウェアフィルター
  • スパムフィルター
  • フィッシングフィルター

の3つでコンテンツのチェックが入る。フィッシングフィルターについては昨年登場した新機能でブログに書いた↓

ATP AntiSpoofingについて

スパム判定されたくない方法

観点1. メールの送信元

接続フィルターに送信元メールシステムのIPアドレスを記載することで、

  • Microsoftブロックリスト
  • Spamhaus

を回避できる。

観点2. メールの中身

ルール(トランスポートルール)に送信元メールシステムのIPアドレスを記載することで、

  • スパムフィルター
  • フィッシングフィルター

を回避できる。ただし

  • マルウェアフィルター

は回避できない。

まとめ

以下のようなメール経路が、最もスパム判定されない経路である。

実装方法についての議論

接続フィルターの代わりに受信コネクタを作成する

Exchangeエンジニアの中には、受信コネクタを作成する事で、Microsoftブロックリストを回避できると案内を受けた人もいると思う。私もその1人であるが、受信コネクタはそもそもMicrosoftブロックリスト回避のための機能ではないし、どちらにせよSpamhausは通ってしまうので、確実にスパム判定を回避できるとは言えない。また、Exchange Onlineエンジニアの間で言われる引き込みの法則という副作用により、冒頭の2の構成で、他テナントへのメールも自テナントに引き込んでしまう動作となる(2,3年前の話。仕様が変わってなければ今も)

受信コネクタがさまざまな条件でメール送信元を指定できるのに対して、接続フィルターはIPアドレスしか指定できない弱点があるが、確実な回避・引き込みの法則を避けるという点で、IPアドレスが判明しているなら、受信コネクタより接続フィルターを利用するのが良いと考える。

接続フィルター 受信コネクタ
対象 CIDR(IPアドレス) ドメイン、トランスポートルール
効果 Microsoftブロックリスト、Spamhausの回避 対象のメールが受信コネクタを使うため、Microsoftブロックリストに追加されにくい?
副作用 なし 引き込みの法則により、広範囲のメールを自テナントに引き込んでしまう

トランスポートルールの代わりに、SPFレコードを登録する

社内メールシステムといえどインターネットを通って(自社の)Exchange Onlineに着信するので、SPFレコードを記載し、スパム信頼レベルを下げる(=信頼できるメールである可能性を高め、スパム判定されにくくする)施策は有効である。しかしながら、SPFレコードはメールの信頼度を高める手段の1つであり、SFPレコードを登録してもその他の要因によってスパム判定されてしまう可能性はないとはいえない。確実にスパム判定を回避するなら、トランスポートルールの方が有用である。

トランスポートルール SPFレコード
対象 さまざまなルール IPアドレス
効果 スパムフィルター、フィッシングフィルターの回避 メールの信頼度の向上
スパム回避効果 確実 ほぼ確実

果たしてOutlookだけで100時間の時短を達成できるのか?

それを確認するには、自分がOutlookを使っている時間数を調べる必要がある。上記の本によれば一般的なホワイトカラーのOutlook利用時間は500時間/年であり、この場合に100時間/年の時短が出来る、とある。

関連エントリ:「年間100時間の時短を実現した32のテクニック アウトルック最速仕事術」を読み込んで改善点を考える

Outlookを起動している時間を調べる

RescureTimeというソフトをインストールする事で、PCで使用しているソフトの利用時間を計ることができる。以下、2019年3月の私のデータ。

Outlookの使用時間は16時間12分。年間使用時間にすると194時間24分。これを100時間にするのは難しそうだが、50時間減くらいなら期待できそう。

ちなみにOutlookより上位のソフトウェアは

  • Microsoft Teams:25時間45分(年換算:309時間)
  • Excel:25時間1分(年換算:300時間12分)
  • PowerPoint:24時間58分(年換算:296時間24分)

なので、Outlookよりも上記ソフトの時短の方が効果があるのだが、以下の理由で時短が難しそう。

  • PowerPoint
    • 手を動かすというより、資料を見たりアイディアを練ったりする時間が大半なので時短効果はなさそう、
  • Excel
    • 既にいろいろExcel本を読み漁ってこの時間なので、単純に触れてる時間が長いだけ、
  • Microsoft Teams
    • アプリ自体がもっさりしており、満足なショートカットキーも用意されておらず時短しようがないので諦めます。マイクロソフト様、時短ハックできるTeamsクライアントをお待ちしています。

それにしても、Teamsがない時代はほぼすべてのコミュニケーションをOutlookでやっていたので、Outlook利用時間(194時間24分) + Microsoft Teams利用時間(309時間) = 年間約500時間もOutlookを利用していたことになる。これならマジで100時間くらいは時短できるかも。

メールの利用時間を調べる

Office 365 を利用しているなら、MyAnalyticsという機能で自分が読んだメールの数・送信したメールの数をカウントする事が出来る。以下は3月第1週目の私のデータ。

2019年3月第1週~第4週の集計は

  • 送信メール:129通
  • 既読メール:1299通
  • メール利用時間:21.4時間

であった。なお時間は単純計算で、送信メールは1通につき5分、既読メールは1通につき2.5分、ただし、連続して既読操作、例えば10通一気に既読にしても2.5分加算となる。詳しい計算方法は以下参照。

MyAnalytics ダッシュボード – Workplace Analytics Office 365 | Microsoft Docs

RescureTimeの16時間42分に比べると少し多いが、メール1通を2.5分かけて読むことはないので、少しMyAnayticsの計算が過剰なように思える。

まとめ

次エントリ年間100時間の時短を実現した32のテクニック アウトルック最速仕事術の紹介をするが、そもそも自分がOutlookを利用していないと意味がないので、事前に調査しておくのが良い。僕に本当に必要なのはMicrosoft Teams時短ハックです。

余談:RescureTimeについて

上でも書いた通り、起動しているソフトウェア毎に起動時間を取得し、レポートしてくれるソフトウェアである。ブラウザでのアクセスの場合、アクセス先のサイト情報も取得してくれる。

元々、ダラダラとyoutubeを見てしまう自分を戒めようと思い導入したのだが、生産的なソフトウェア(Outlook・Excel)、非生産的なソフトウェア(Chromeでyoutubeを見る、LINE)を分けて集計してグラフィカルに表示してくれるので便利。月毎の比較もでき「前月に比べてX時間生産的な時間が増えた」というレポートも出してくれる。PCのフロントウィンドウになっているソフトウェアの情報を取得しているだけなので、Excelを起動したまま離籍したり、youtubeを流したまま寝落ちするとその時間も加算されるのだが、絶対時間ではなく週毎、月毎のデータで比較する事で肌間隔的に分かる(今週は先週に比べて頑張ったな)ので、ひとまずいいかな、と。

今後、ここで取得したデータを元に自分の行動を変えていけたら、と思っている。

「年間100時間の時短を実現した32のテクニック アウトルック最速仕事術」を読み込んだ

はじめに

年間100時間の時短を実現した32のテクニック アウトルック最速仕事術は時短ハックの対象としてOutlookにフォーカスした本であり、その着眼点と内容もすばらしく、年間のOutlook利用時間が多いが特に使い方を工夫していないユーザー、また工夫しているがより良い使い方があるかを確認したいユーザーは購入必須である。

私としては、自分なりにOutlookを工夫して使っており、Outlookを人に教える事もある立場であるため、あえて批判的な視点で本書のテクニックを確認していくが、本書の基本的なコンセプト「普段意識しないOutlookの使い方を見直し、時短につなげる」は大賛成であることは記載しておく。

これを機にOutlook時短ハックブームが起こり、みんながOutlookの効率的な考え方についてあーでもないこーでもないと議論できる世の中になれば私も本望である(それはなさそう)

本書のテクニック一覧と、私の評価

2章:画面の使い方編

Case1:予定表を固定する

著者の意見

メール一覧画面の右ペインに予定表を固定し、いちいち予定を確認するために予定表ビューに移動しなくてよいようにすべし

私の意見

ディスプレイが広い場合は賛成だが、狭い場合はメール一覧画面が小さくなって、「メッセージのプレビュー」機能による本文表示(≠閲覧ウィンドウ)領域が小さくなり、かえって情報量が少なくなる。タスクバーを立て置きにしている場合はなおさら。自分の予定の量の多さと相談して、何をランディングページ = メールの一覧画面に表示するかを検討すべし。

下に比較画像を配置した。

・メール一覧画面だけ
右側の領域に情報量が少なく非効率な気がする

・メール一覧画面 + 予定表ビュー
ちょうどいい情報量

・メール一覧画面 + 予定表ビュー + タスクバー
メール一覧画面の情報量が少ない気がする。

Case2:添付ファイルは最初につける

著者の意見

クリップボードにファイルを選択した状態でメールに張り付けると、ファイルが添付された状態の返信メールが立ち上がるので有効活用すべし

私の意見

私の添付ファイル付きメールの送信数を調べたら月に20通くらいだったので、仮にこのテクを利用してもあまり時短は望めないように思えた。また、メール処理のプロセスが

  1. 受信トレイのメールを見る
  2. 対応必要そうなものは返信メール画面を起動
  3. 本文を書いて添付ファイルをつける

なので、2の時点でこのテクニックは使えない。このテクニックを使うには、自分のメール処理のプロセスを変える必要がある。

Case3:予定表から新しいタスクを起動しない

著者の意見

クリップボードにテキストをクリップして予定表ビューの時間帯を選んでペーストすると、予定が作成される機能を使うべき

私の意見

反映されるのはクリップボードのテキストだけであり、添付ファイルはペースト出来ないのが欠点。本書では「イベントへの招待のメールを予定表に張り付ける場合」に便利とあるが、それに添付ファイルがあった場合、結局.msgファイル自体を予定表に張り付ける必要があるので、

  1. 受信トレイの招待メールをクリップボードにコピー(この時点で、.msgファイルとしてクリップ)
  2. Ctrl + Shift + Qで空の予定表アイテムを起動
  3. ペースト(.msgファイルがペーストされる)

が最速の手段となる。.msgファイルを新規アイテムに張り付ける”入れ子のメッセージ機能”はメッセージそのものを完全に保管できるので結構優秀。余談だが、Office 365 の場合、30入れ子までの動作をサポートしている。

Case4:メールの閲覧ウィンドウは使わない

著者の意見

メールの閲覧ウィンドウは画面占有率の割に情報量が少ないので閉じるべし

私の意見

賛成。余白が多く、無駄である。私は「メッセージのプレビュー」機能を利用し、2行ほど本文を表示しサマリが分かるようにしている。全文を読みたい場合は、著者の意見通り、別ウィンドウで開いている。

Case5:リボンは閉じる

著者の意見

ショートカットキーを使いこなせばリボンは不要だから閉じるべし

私の意見

メールの読み書きなら不要だが、予定表を利用するときはショートカットキーだけでは操作できない事が多いので閉じない方がよい。例えば予定を「非公開」にしたり、公開方法を「空き時間」にするのはショートカットキーが用意されておらず出来ない。

私からはリボンの代わりによく使うボタンをクイックアクセスツールバーに集約する事を提案したい。PC毎に設定が必要という欠点はあるが、これでリボンを表示させなくても済む。

例えばTeams会議開催ボタンをツールバーに追加したり。

3章:ショートカット(基本編)

この章のショートカットは知っていて当然レベルでマスターしたい。以下を本書への補足。

  • 返信(Ctrl + R)で紹介されている全員返信(Ctrl + Shift + R)はCtrl + Lでも可能。→Alt + Lでした。
    • ビジネスでは全員返信でメールを作成する事が多いので、返信 = Ctrl + L→Alt + Lで覚えた方がよい。
    • (2019年5月2日追記)著者から指摘あり、全て左手で操作できる統一感と、なるべくCtrl系でショートカットは統一したかったのでAlt + LよりもCtrl + Shift + Rにしたとの事です。
  • 閲覧ウィンドウを閉じる(Esc)はAlt + F4でも代用可能。
    • Alt + F4はWindows全般で有効なので、これで閉じてしまってもよい。
  • 次 or 前のメールへ移動(Ctrl + < or >)は、Ctrl + 4 or 5でもOK。
    • これはショートカットバーに前後のメールに移動するボタンが標準で表示されているから使える。
    • <と>はPCによっては位置が探し辛いので、4と5で覚えるのがよい。

4章:メール整理

著者の意見

仕訳ルールは使わず、アーカイブフォルダを上手に使え。仕訳したくなったら検索フォルダを使え。

私の意見

仕訳ルールを作ってフォルダ分類派 VS メール処理状態で整理派の仁義なき戦いである。まず大事なのは、どちらも試して、自分に合った方法でやってみる事である。また、環境が変わった場合、やり方を見直すのも重要である。

なお私はどちらも試して仕訳ルールを作ってフォルダ分類するやり方に落ち着いたが、この本を読んで数年ぶりに仕訳ルールを全削除し、メール処状態でフォルダ整理運用にした。なぜなら、数年前に試した時はビジネスチャットツールであるMicrosoft Teamsがなく、全てのコミュニケーションをメールでやり取りしていたが、今は大半がTeamsに移行し、メールの総数が減ったからである。新規OAツールが導入されたり転職したりして環境が変わった場合、今までのやり方が最適ではなくなる可能性があるため、環境が変わる前に自分のやり方を見直すことが重要である。

なお著者が推薦している検索フォルダはOWAやOutlook for iOSでは利用できないため、ブラウザやモバイルデバイスからメールを利用することが多い場合、検索フォルダに頼ることは出来ない。本書は全般的にデスクトップ版Outlookでメールの処理をする事に主眼が置かれているため、自分の使い方がどの程度合致しているかを見極めて読む必要がある。

5章:もっと時短したい人のためのスーパーテクニック

クイック操作 / クイックパーツ

著者の意見

自分好みにクイック操作やクイックパーツを利用すればもっと時短できる。

私の意見

この2つの機能は自分のOutlookの利用方法を分析して、使い方を検討する必要がある。例えば「クイックパーツで定型文を登録すれば時短になる」と著者は主張するが、私の場合、月のメール送信数は129通(前エントリ:果たしてOutlookだけで100時間の時短を達成できるのか?の調査結果参照)。この129通のうち、定型的な内容で返信しているメールが何通あり、クイックパーツによってメールを作成する事で短縮できる時間は何分か?

日本人の平均タイピング速度は100文字(ひらがな)/分らしいので、クイックパーツが100文字程度であれば、1通につき1分ほどの時短。クイックパーツで作成できるメールが10通あれば10分の時短、年間では120分の時短となる。しかしながら、そのためにテンプレートを作成し、クイックパーツを設定し、送信するタイミングでクイックパーツを思い出すコストはどうか?ついつい手打ちしてしまうこともありそう。

なお私の場合、129通のメールで定型的な内容で返信しているメールは2通だけだったので、絶対に普通に返信した方が早いです。自身の毎月のメール送信数を調査し、効果を算出してから、取り組むのがよい。

Oftファイルでのスケジュール確認機能

著者の意見

Oftファイルの宛先に同僚のメールアドレスを登録することで、スケジュールアシスタントから簡単に予定を確認できる

私の意見

予定表グループでも同じような事ができるのに、なぜOftファイルでスケジュール確認をするのかよくわからなかった。
もし、(予定表グループの)予定表ビューを使った予定表閲覧は時間がかかるから、あえてスケジュールアシスタントから確認したい、というのなら、同僚のメールアドレスを連絡先や連絡先グループに登録して、会議出席依頼から確認すればよいと思った。

なおOftファイル自体は有用な機能であり、例えばヘルプデスクで定型文をグループで共有する場合、グループでアクセス可能なディレクトリに返信テンプレートを配置し、それを元に返信する、という事が出来る。

(2019年5月2日追記)著者から指摘あり、Oftファイルは、部内のファイルサーバーなどで共有して利用する想定、とのことでした。確かにこの使い方なら、自分の予定表グループをメンテするより、グループ全体で利用できるからいいかも。一番いいのは、システム管理者が組織構造に合わせたグループを作成し、グローバルアドレス帳に公開することだと思うが。

メールの1分遅延ルール

著者の意見

クライアントルールで1分遅延ルールを設定すると無料で誤送信防止ができる

私の意見

これはマジお勧めで、著者の提案する例外ルールを設定するのも併せてお勧め。注意点としてOutlookで送受信タスクが走るタイミングで、送信トレイに1分以上保管されたメールが送信されるので、最速で1分、最遅で2分くらい、送信にかかること。あと、Outlookのクライアントルールになるので、OWAやOutlook for iOSの時には適用されないので注意。

6章:もっと時短したい人のためのショートカット

気になったところだけ。

Ctrl + Space = 標準書式に変換

これは知らなかったので活用している。Outlook以外から文章をコピーした場合にMeiryoで統一されたフォントにMS ゴシックがまざってイラっとしてしまう所がこれで直せるのは便利。

Ctrl + Shift + I で受信トレイに移動

これは知らなくて便利だと思いました。が、送信済みトレイに移動するショートカットもほしかった。

署名のショートカット

クイックアクセスツールバーに登録する事で、Alt + 1で署名のショートカットを呼び出せる、というテクニック。だが私はOutlook標準のショートカットである、Alt -> N -> AS で署名を呼び出してます。慣れれば1秒かからない。

仕事柄、複数のPCでOutlookを使うことがあるので、ソフトウェア固有の設定をいじるのが煩雑で管理しづらく、出来るだけ標準ショートカットで済ますようにしています。

Shift + 右クリック = パスをコピー

これは自社の共有ストレージが

  1. 全員が同じUNCパスでアクセスできるファイルサーバーか
  2. https://~でアクセスする、オンラインストレージか

で有用性が変わってくる。うちの会社はほぼファイルサーバーが廃止されSharePointが主要ストレージ。SharePointのファイルにアクセスするには

  1. ブラウザからファイルを選択する
  2. OneDriveで同期して、ローカルファイルとして開く

の2通りがあるのだが、2で同期したファイルのパスは自分のPC固有のパスとなり人に送っても開けない。

よって、https://で始まるパスを人に伝えなければならないが、この時に便利なのが「ドキュメントの場所」というクイックアクセスツールバー。

Alt + 数字で、ドキュメントを開いたままパスをクリップボードにコピーできる。

編集し終わったファイルのパスを誰かに伝える、という利用シーンを考えても、わざわざエクスプローラーに戻ってパスをコピーするよりも有能。「ソフトウェア固有の設定をいじるのは嫌」といいつつ、これだけは代替のショートカットがないので、設定している。

また余談だが、book1.xlsxのような一時的なドキュメントを他人にシェアしたい時、一度PCに保存してからメール添付ではなく、ワンボタンでメール添付できるような機能も設定している。

まとめ

本書の基本的なテクニックは抑えるとして、応用編は自分のOutlookの利用分析を行った上で適切なテクニックを覚るのがよいと思う。特にクイック操作、クイックパーツ、クイックアクセスツールバーは使う人と設定内容によっては福音になる(SIerとしても一度これを使った業務改善を提案した = カネが取れる)ので、Outlook利用頻度が多い人は研究してほしい。

一方、予定表の活用テクニックがあまり記載されていなかったのが弱点かと思われるが、Outlookでメールは使っているが予定表は使っていない会社は意外と多い事、メール利用に比べて予定表利用の方が個別最適化されて汎用化しづらい事から、書籍として出すのは難しかったのかな、と思う。

全てのテクニックが有用だとは思えないが、冒頭にも書いたが、みんながなんとなく使っていたOutlookに光を当てたという点で、本書は素晴らしいです。著者は「Excelのスキル本はあったがOutlookはなかったので書いた」と言っているが、ExcelはVLOOKUPを使わなければ出来ないことはあるが、本書のOutlookテクを使わないと出来ないことは、正直言ってない。しかしながら、Outlookは万人が使用し、VLOOKUPと違って全員に効果があるテクニックが本書には書かれてますので、Outlook主体の業務の人は是非チェックしてみてください。

なお私はMicrosoft Teamsの使い勝手が良くなることを心より期待しています。

onmicrosoft.comがバレると何が困る?

前回のエントリの続きです。

onmicrosoft.comをどうしても隠蔽したい – ぷりどうぐ

前回のエントリの結論:xxx.onmicrosoft.comを隠し通すのは難しい

onmicrosoft.comがバレると何が困る?

困る事もありますが、別にそうじゃなくても既にバレてるので困らないこともあります。

Office 365 を利用している事がバレる

xxx.onmicrosoft.comがバレる = Office 365を使っている事がバレるので、フィッシングメール送って偽のログイン画面に誘導できたりする。ただOffice 365利用しているかどうかは会社のメールアドレスを知っていればnslookupで一発で調べられるので、xxx.onmicrosoft.comを隠しててもバレます。

結論:どっちにしてもバレてるので無影響

AADログインIDのonmicrosoft.comドメイン部分がバレる

会社のログイン用ドメインはメールアドレスと同じ場合が多いので当然外部にバレてるとして(※)、新たにxxx.onmicrosoft.comのドメインがバレると、xxx.onmicrosoft.com を利用したユーザーIDを探してログイン施行することが出来ます。企業のもつアカウントの99%くらいは会社ドメインのログインIDなので問題なさそうなのですが、xxx.onmicrosoft.comを持つIDはシステム導入時やテスト時に作ったまま放置しているアカウントだったりして無防備なことが多いので、事実上、問題になる事があります。

※ まれに「悪意のある外部ユーザーからログイン施行されないため、ログインする会社ドメインをメールアドレスと別のものにしたい」という要望を受けますが、ゼロトラスト理論を考えるとそれこそ隠し通すことが難しく、ユーザー利便性だけが低下するのでやめた方がいいと思われます。

結論:アカウントが存在する場合は問題あり

onmicrosoft.comのセカンダリメールアドレスがバレる

Office 365 の仕様上、各ユーザーのセカンダリメールアドレスに[ユーザーID]@xxx.onmicrosoft.comというメールアドレスが付与されるので、スパムメールを送りやすくなります。とはいえ、セカンダリメールアドレスを指定しなくても普通に会社ドメインのメールアドレス[ユーザーID]@xxx.co.jpにメールを送り付ければいいので、onmicrosoft.comがバレたことによって新しく困る事ではありません。

結論:どちらにしろメールは受信できてしまうので、無影響

SharePointサイトのURLがバレる

会社のイントラのURLがバレるので気持ち悪い、という意見。とはいえ、SharePoint外部共有やTeams外部招待、OneDriveファイル共有を許可している会社なら、自サイトへのユーザーアクセスを許可しているわけで、今更会社のイントラURLバレを気にするのもナンセンスかと思います。

SharePoint外部共有とかしてないから、イントラのURLがバレるのが気持ち悪い!というのは感覚としては分かりますが、メールと違って権限管理をすれば外部から見れないので全く実害はないです。

※ むしろメアドさえ知ってれば誰でもメールを送れてしまうメールの仕組みがすごい

結論:デフォルトで外部の人は見れないから、バレたところで無影響

結論まとめ

AADログインIDのonmicrosoft.comドメイン部分がバレるのが、onmicrosoft.comがバレることによる新たなデメリットと考えます。

ログインIDがonmicrosoft.comのアカウントってどんなの?

xxx.onmicrosoft.comを利用したユーザーIDを抹殺すればよいですが、そんなことはできるのでしょうか?どのようなアカウントがonmicrosoft.comを使うのでしょうか?

認証回避

結論から言うと、一般ユーザーアカウントに対して多要素認証などを仕掛けている場合に、多要素認証トラブル時のシステム復旧用に、多要素認証を回避するためのアカウントを用意するパターンでonmicrosoft.comドメインを使う場合があります。

フェデレーション認証環境の場合

O365の世界でフェデレーション認証は認証ドメイン単位で設定するので、例えば会社ドメインはフェデレーション認証、としてしまうと、緊急回避用アカウントは会社ドメイン以外で作成する必要があります(※) ここで、既定で用意されているxxx.onmicrosoft.comを認証用ドメインとすることがあります。

以下の記事でもそれが推奨されています。

緊急アクセス用管理者アカウントの管理 – Azure Active Directory | Microsoft Docs

※ 緊急回避用アカウントを会社ドメインで作成しつつ、フェデレーション先のIdPで多要素認証をかけないこともできるが、どちらにせよIdP自体が死んだときは影響あり

AzureAD認証環境の場合

AzureAD認証環境の場合、認証制御はEM+Sの機能で行います。EM+Sの制御単位はユーザー個別orセキュリティグループであり、認証ドメインがなんであるかは関係ありません。よって、緊急回避用アカウントを会社ドメインで作成しても問題ありません。

結論

  • フェデレーション認証環境の場合は、会社ドメイン以外のドメインで、緊急回避用アカウントを作成する必要がある
  • AzureAD認証環境の場合、会社ドメインで緊急回避用アカウントを作成すればよいので、onmicrosoft.comでログイン可能なアカウントを抹殺できる

一歩進んで考察

さて、フェデレーション認証環境ではonmicrosoft.comのアカウントが必ず必要なのでしょうか?会社ドメイン以外のドメインで、緊急回避用アカウントを作成する必要があるという条件を満たせばいいので、例えば @hogehogetest36512345678.com というドメインを取得し、Office 365 に紐づけ、emergencyadmin@hogehogetest36512345678.com みたいなアカウントを作成し、、この条件を満たせますよね。

よって、ADFS環境でonmicrosoft.comの緊急回避用アカウントを作成する必要はなく、会社ドメインとは別の、AzureAD認証を利用するドメインを用意すれば、ADFS環境でもonmicrosoft.comも抹殺できます。

しかし果たしてこれに本質的な意味はあるのでしょうか?

emergencyadmin@hogehogetest36512345678.comと、
emergencyadmin-hogehogetest36512345678@xxx.onmicrosoft.comは「複雑で推測されにくい」という点で、何が違うのでしょうか?

上司に「なんでhogehogetest36512345678.comってドメイン取るの?」って聞かれて、ロジカルに答えられるでしょうか?
hogehogetest36512345678.comのドメインを維持する労力や、ドメイン失効リスクの方が、onmicrosoft.comを利用されるリスクよりも高いんじゃないでしょうか?

相次ぐドメイン事件、目的のWebサイトが表示されない原因 | 日経 xTECH(クロステック)

と考えると、素直にxxx.onmicrosoft.comのドメインを利用し、緊急回避用アカウントのIDを複雑にすることで(もちろんパスワードも)十分に要件を満たせるのではないでしょうか?

AzureADの素のセキュリティ

EM+S使わないと脆弱だ!みたいな説もありますが、AAD素の機能でそれなりのセキュリティレベルは担保しています。例えばID/Passwordを複雑にする、という対策は、IdPが総当たり攻撃を許してしまえば全くの無力ですが、当然その対策はされています。

詳しくは以下エントリを読んでもらいたいし、私も昔に説明エントリ書いてました。

Azure AD と AD FS のベスト プラクティス: パスワード スプレー攻撃の防御 – Japan Azure Identity Support Blog
Azure AD スマートロックアウトのカスタマイズ機能について-ぷりどうぐ

よって、IDもパスワードも複雑にしておけばまず大丈夫、と言えるでしょう。

結論

  • ADFS環境でもonmicrosoft.comのログインIDは抹殺できるが、ナンセンスで無意味なので、onmicrosoft.comのIDを抹殺する意味はない。
  • AzureADのセキュリティ機能を信用し、辞書攻撃にヒットしないようなID/Passwordを作れば、AzureADが総当たり攻撃には対応してくれる。

onmicrosoft.comをどうしても隠蔽したい

お客様より「xxx.onmicrosoft.comは外部にバレたくないしユーザーにも見せたくない」という要望を受けますが、実現可能なのでしょうか?

xxx.onmicrosoft.com とは?

Office 365(Microsoft 365)の契約毎に割り当てられる一意のドメインであり、契約後は変更不可。独自ドメインを持っていないユーザーや、検証環境で気軽に使えるようにと用意されたものだが、本番環境では会社のドメイン(xxx.co.jp)を使うのが普通であり、xxx.onmicrosoft.comは不要となる。

※ 私のテナント。myalmea.onmicrosoft.com が xxx.onmicrosoft.com であり、Office 365 契約時に割り振られるもの(名前は自分で選べる)。almea.jpが自分所有のドメイン。

以下、本番環境であることを前提に話す。

なぜ隠蔽したいのか?

よくある2大理由。

1. ユーザーに見せたくない

会社ドメイン xxx.co.jp しか利用していないユーザーが突如 xxx.onmicrosoft.com を見てしまったら「xxx.onmicrosoft.comって何ですか?スパムですか?」とユーザーの混乱を招き、不要な問い合わせが発生する可能性がある。

2. セキュリティ的によろしくない

理由はいろいろありますが、onmicrosoft.comを利用してクラッカーに狙われる恐れがある。詳しくは別エントリ。

onmicrosoft.comが表示されちゃう場所

SPO、Skype、ExOL、Teamsの四天王を論じる。Swayとかは知らん(私がナレッジなし)

SPO(OneDrive)

SPOサイト自体にxxx.sharepoint.comという名前付けがされるので、内部ユーザーには見えてしまう。例えば、自分のOneDriveを利用するときに見える。SPOやOneDriveで外部共有をする場合、xxx.sharepoint.comが含まれる形で共有するため、外部ユーザーにバレてしまう。

Skype

Skypeはテナント側でデータベースのようなものは持たず、あくまで個人の連絡先を情報として閲覧できる形となる。連絡先はAzure AD のSIPアドレスが見えるため、こいつが会社のドメインであれば、xxx.onmicrosoft.comは見えなかったはず(最近構築してないから怪しい
まぁほぼTeamsに置き換わってるからいいや…。

ExOL

明示的にメールアドレスを付与しなければ、[ユーザー名]@xxx.onmicrosoft.comというメールアドレスが付与される。明示的に会社メアドを付与した場合でも、セカンダリアドレスにというアドレスが強制的に付与されるので、[ユーザー名]@xxx.onmicrosoft.comでメール受信ができてしまう。

「明示的にメールアドレスを付与しなければ」というのは、Teamsでチームを作成した時にも当てはまるので、ユーザーが自由にTeamsを作れるシナリオだと、作るそばから@xxx.onmicrosoft.comで送信可能なメールボックスが出来上がっている(※)、ということになる。

※ 2019/4/23追記
Teamsからチームを作成した際に出来る共有メールボックスに対しては「メールボックス所有者として送信する」権限が付与されないので、設定変更なしにメールを送ることはできませんでした。すいません。

また、国井さんのブログにもあったが、メアドを隠蔽してもO365の仕様上、テナントからメール送信時にDKIM署名をするので、ヘッダーにxxx.onmicrosoft.comのドメインが記録される

Teams

ユーザーとしても管理者としても利用していますが、onmicrosoft.comが見えてしまう場面はない。ただこれはTeamsのUI上では、という条件付きであり、裏側のSPOやExOLを開いた瞬間にxxx.onmicrosoft.comがバンバン見える。これはSPO,ExOLの項目で説明していく

隠ぺいの検討

SPO

内部アクセスの際にxxx.onmicrosoft.comの代わりにxxx.co.jpを使わせるよう、内部DNSにCNAMEを記載して隠蔽することが出来る。しかしnslookupでCNAMEの変換先を引けばバレてしまうし、ファイル共有を使うと自動的にonmicrosoft.comを含まれるアドレスが発行されるので隠蔽は難しいと思う。

ExOL

メールフロー

トランスポートルールでxxx.onmicrosoft.comが含まれるメールは破棄する設定にしておけば防げる。ただ、マイクロソフト社からの通知メールなどがxxx.onmicrosoft.com宛に送られてきても破棄するので注意する。前に問い合わせた時は、通知メール系はプライマリメールアドレスを見ているとのことなので、管理者IDをxxx.onmicrosoft.comのまま運用する場合は、UPNはそのまま、プライマリメールアドレスをxxx.co.jpにしておく。

セカンダリアドレス

ユーザーオブジェクトにはxxx.onmicrosoft.comが付与されたままなので、Outlookの連絡先カードを使うと一般ユーザーでもxxx.onmicrosoft.comの確認が可能。隠蔽不可。

DKIM署名

DKIM署名にxxx.onmicrosoft.comが記録されちゃう問題は、DKIM署名を無効にすることで回避できる。

DKIMを無効にする賛否はあれど、日本国内では4割程度の実装であるため無効にしても即スパムとは扱われにくい事、3rdパーティーMTAをかませて、そこでDKIM署名を行うことで回避できること、DMARKを使うことが代替策となる(DMARKだけは実装したことないので、実はこいつもonmicrosoftを外に出す可能性はある)

まとめ

内部漏洩

SPOのサイト、OneDriveの自領域、Outlookより自分の連絡先情報を見る、など手段がありすぎて隠蔽は難しい。

外部漏洩

自テナントのSPOサイト(OneDrive含む)にアクセスさせない、メールフローの隠蔽、DKIM署名の削除で対応できる。

よって、バレるのは内部ユーザーだけなので安心!…というわけにはいかず。ゼロトラスト理論だと内部ユーザーを信用しないし、仮に信用してもこんだけ埋め込まれてたらどっかから漏れるでしょということで、バレる前提で考える、隠蔽するのに無駄な工数をかけない方がよいと思いました。

Azure SentinelでOffice 365 のデータを取り込んでみた

※ 本エントリは単純にAzure Sentinelを有効にしただけで、特に深い考察はありません。

唐突に”Azure Sentinel”なるものがリリースされました。

O365やAzureだけではなく、さまざまなログを取り込んでリアルタイムでモニタ出来る、というどこかで聞いたことあるサービスです。現在はプレビューなので無料ですが、「Office 365アクティビティデータの取り込みは、サービスの本格提供開始後も無償」とのことなので、さっそく取り込んでみました。

続きを読む

Exchange Server 2013以降に存在する脆弱性”PrivExchange”の内容と対処法(とその影響)

本記事は英文記事をベースに実機検証なしで書き上げたものであり、内容が誤っている可能性があります。本記事を参考にしたことで問題が発生しても責任は取りませんのでご了承ください。

ドメインユーザーのID/Passwordだけでドメインコントローラーを乗っ取れる、衝撃の脆弱性が発見されました。

脆弱性の内容

今回の”PrivExchange”は、Exchange Serverの複数の脆弱性/設定を組み合わせて動作するものです。

1.EWSの”PushSubscription”を利用して、Exchange Serverに認証行為を開始させる

最初にExchange ServerのEWSを利用します。EWSの”PushSubscription”機能を利用すれば、Exchangeに対して任意のURLに対して認証を行わせることが可能です。この例では、Exchange Serverに命令して、攻撃者のPCに対してExchange Server権限で認証を試行させます。

※ EWSを利用するため、ExchangeユーザーのID/Passwordを利用します。

で、元記事の”Performing the attack without any credentials altogether”にあるのですが、ネットワークパケットをコントロールできる立場なら、ユーザーのID/Passwordを知らなくても、同一セグメントの一般ユーザーの認証パケットをExchange Serverに投げることで同じことが出来ます。

2.NTLM認証にハッシュが付与されていないため、中間者攻撃を行うことが可能である。

これはExchange Serverではなく、昔からWindows Server自体に存在する脆弱性となります。以下、2004年(15年前)の記事。

Windows NTLM認証とマン・イン・ザ・ミドル攻撃

1.でExchangeに対して攻撃者のPCに認証を行わせるように仕向け、その認証をDomain Contorollerに転送することで、中間者攻撃が成立します。これにより、攻撃者のPC = Exchange Serverのコンピューターアカウントに成りすますことができます。

で、ここが記事を読んでもいまいちわからないのですが、おそらくDomain Controllerが受け付けられる認証方式ならなんでもいいようです。具体的には、ExchangeユーザーのID/Passwordを使って認証を成功させるパターンの場合、HTTPプロトコル経由でNTLM認証(マン・イン・ザ・ミドル)攻撃を行います。ネットワークパケットをコントロールするパターンの場合、SMBプロトコルを使って同じことをやります。

どちらも、マン・イン・ザ・ミドル攻撃を完了した後、Domain ControllerのLDAP認証に中継します。

3.Exchange Serverのコンピューターアカウントに、過剰な権限が割り振られている

脆弱性、というよりは仕様上の欠点ですが、Exchange Server(のコンピューターアカウント)はActiveDirectoryに対して非常に強い権限を持っていまづ。これにより、1と2の方法でExchange Serverのコンピューターアカウントを乗っ取り、Domain Controllerに対して認証を成功させることで、ActiveDirectoryに対して自由に操作が出来てしまう状況です。

アタック方法

Githubで公開されている簡単なスクリプトを利用すればいけそうです。

GitHub – dirkjanm/PrivExchange: Exchange your privileges for Domain Admin privs by abusing Exchange

影響をうける環境

この脆弱性を利用してADを乗っ取るには

  • Exchange ユーザーのID/Passwordを知っている事
  • Exchange Serverに対してEWSアクセスできるネットワーク環境にいること
  • ActiveDirectoryに対してNTLMアクセス可能なネットワーク環境にいること

が必要です。また、

  • NTLMv1が有効であること

が条件のように思われます(元記事の”The technical bits – relaying to LDAP and signing”によると、NTLMv2ならMICと呼ばれるハッシュ値を改ざんできず、マン・イン・ザ・ミドル攻撃が失敗する)

悪意のある社外ユーザーに攻撃されるか?

  • Exchange ユーザーのID/Passwordを知っている事
    • 通常は知りえないが、漏洩したID/Passwordを知られている可能性があるので、危険性あり
  • Exchange Serverに対してEWSアクセスできるネットワーク環境にいること
    • 外部からのEWSアクセスを許可している場合があるので、その場合は危険
  • ActiveDirectoryに対してNTLMアクセス可能なネットワーク環境にいること
    • ADを外部に公開しているケースは少ないと思われる。攻撃者がADに接続できなければセーフ。

ADにアクセスさえできなければ、ADを乗っ取られる可能性はないです。それでもExchange Serverへの攻撃は通ってしまいますが…。あるいは、EWSを外部公開していないとかだと安心です。

悪意ある社内ユーザーに攻撃されるか

一般的な社内ユーザーは上記条件を満たしているので、簡単に攻撃が出来ます。

対処法(案)とそれによる影響

マイクロソフト社から正式な修正パッチが出るまでは、解説記事で触れられている方法で対応するしかなさそうです。しかしながら、一部対応はマイクロソフト社非推奨の内容であり。実行にはリスクが伴うものもあります。

対処法1. EWSの機能を制限

EWSにさえアクセスできない/使えないならこの攻撃は成立しないので、EWSを無効化、あるいは以下のコマンドで、EWSのpushsubscriptionsを無効化することができます。

New-ThrottlingPolicy -Name NoEWSSubscription -ThrottlingPolicyScope Organization -EwsMaxSubscriptions 0
Restart-WebAppPool -Name MSExchangeServicesAppPool

本対処方法はマイクロソフトが推奨するものではなく、EWSの動作に必要な機能まで無効化される可能性があります。

対処法2. LDAP Channel bindingの有効化、SMB署名の有効化

LDAP Channel bindingの有効化またはSMB署名の有効化を行うと、それぞれのプロトコルで改竄が出来なくなるようです。

SMBを防いでもEWSに対してHTTPアクセスし、NTMLへのマン・イン・ザ・ミドル攻撃をすればLDAP認証までたどり着けるので、根本解決はLDAP Channel bindingかと思われます。

対処法3. Exchange Serverのコンピューターアカウントから、過剰に付与されている権限をはく奪

Githubに公開されているツールを利用して、Exchange Serverのコンピューターアカウントから、過剰に付与されている権限をはく奪することができます。

使い方は以下記事の中盤を参照

Import-Module ServerManager
Add-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory
.\Fix-DomainObjectDACL.ps1

で、現状の危険な権限を列挙し

.\Fix-DomainObjectDACL.ps1 -Fix

で修正を行えます。

本対処方法はマイクロソフトが推奨するものではなく、Exchange Serverの動作に必要な権限まではく奪する可能性があります。

対処法4. NTLMv1プロトコルの無効化

元記事を読む限り”NTLMv1プロトコルの無効化すれば解決じゃね?”と思うのですが、元記事の解決策には書いておらず、NTLMv1の無効化が正しいかどうか不明です。

マイクロソフト社の動き

2019/1/31では公式声明はないですが、MSとつながりの深い海外のエンジニアいわく、マイクロソフトが解決のために動いているとのことですが、公式ソースは出ていません。

Serious Exchange Server vulnerability reported

But, before going any further – Microsoft is actively working to resolve the issue as quickly as possible, so expect to hear more from the Exchange team in the coming days.