見出し画像

OSの認証とIDaaSについて

IDaaS提案時に「OSの認証(デバイスのログイン)にも対応していますか?」とよく聞かれることがあります。
デバイスの管理の一部も機能として持っていて欲しいという背景があるからです。

今回はOSの認証に対する要望であったり、IDaaSベンダの対応状況などを記載させていただきますので、IDaaS導入時の参考にしてください。

OSの認証

企業で使われるPC(デスクトップ)向けOSで多いのは、やはりWindows 10です。最近はMacもだいぶ増えてきていますし、BYODに取り組み始めている企業もあり、管理するのであればWindowsとMacのどちらか一歩だけ管理とはいかなくなっています。

ChromeOSも最近CMなどではよく見たりしますが、まだ現場ではほとんど名を聞かないです。個人的には期待しています。

OSの認証というのは、上記Windowsの端末などにログインするための認証のことです。特にWindowsは認証方式がいくつかありますので、簡単に記載します。ここは不要であれば読み飛ばしちゃってください

本記事ではOSの認証とIDaaSについて、以下3つのポイントを中心に整理していきます。
・シングルサインオン(認証)
・セキュリティ
・運用

WIndowsのアカウントと認証

■ ローカルアカウント
ローカルアカウントとはそのデバイスのみに存在するユーザであり、パスワードもそのデバイスの中だけにしかありません。
パスワード忘れにより、ログイン不可の際にりデータ損失するなどの可能性があるので、企業で管理されるデバイスでそのまま業務用に使われることはありません。ディレクトリがない小規模な会社では利用されていたり、いざという時のデバイスの管理者アカウントとして使われます。

■ Microsoftアカウント
Microsoftのサービスを受けるためにクラウド上に登録するアカウントです。ローカルアカウントとは違い、クラウドサービスや別のデバイスのアカウントとして紐づけることができます。
1つのアカウントをサービスで共有するので、認証時に利用するパスワードはすべて同じになります。OfficeサービスなどのライセンスをもつMicrosoftアカウントであれば、複数のデバイスでOfficeの利用ができるようになります。
主に個人利用であったり、Azure ADを利用していない企業で使われます。

■ Domain User(Domain Join)
Windows 10以前の時代から企業に最も活用されていたものです。
企業で従業員をActive Directory(以下AD)で一元管理している場合、デバイスのログインにADで管理するアカウント(Domain User)を使うことができます。
同じ企業で管理されているデバイスであれば、どのデバイスを使っても同じIDとパスワードでログインできます。ADでポリシーの管理したり、大学など利用者と利用デバイスが一定でない場合などに活躍します。

ADがオンプレミスに構築されるのものであるため、ネットワークが課題となりがちです。あまり推奨はできませんがリモートワークなどに備えて、VPNで社内ネットワークに引き込んだり、クラウド上にADをホスティングしたりなどで対応しているところもあります。

■ Azure AD User(Azure AD Join)
考え方としてはMicrosoftアカウントと変わりません。企業で管理しているAzure ADのアカウントでログインします。
Domain Joinから、Azure AD Joinに移行しようとしているところが多いですね。

なお、Hybrid Azure AD Joinというものもありますが割愛します。
簡単に言うとAzure ADにADの認証情報でログインする感じです。

キャッシュログインとは

本来であれば管理されているアカウントで認証するためには、Domain Joinデバイスであれば社内ネットワーク、Azure AD Joinデバイスであればインターネットに繋がっている必要があります。
しかし、ネットワークに接続できていないとPCにログインできないということではありません。

2回目以降のログインであればデバイスが、前のログイン情報を覚えている(キャッシュしている)ので、前回と同じIDとパスワードを入力することでログインすることができます。
逆に言うと、ADなどでアカウントのパスワードを変更していても、ネットワークにつながなければ、変更前のパスワードでログインできてしまいます。

シングルサインオン(認証)における要件

さて、ここからが本題となります。OSの認証に求められているものは何なのでしょうか?
「OSの認証(デバイスのログイン)にも対応していますか?」という質問はその背景によってさまざまな見方ができます。

まずは「シングルサインオン」というキーワードで見ていきましょう。
一度認証してしまえば、クラウドサービスでもOSの認証でも認証操作を一回だけにしてしましたいという要件ですね。

多くの場合において、サービスを利用するより先にデバイスの認証が走りますので、シングルサインオン環境を実装しようとすると以下パターンになります。
・デバイスの認証の”前”にIDaaSで認証する
・デバイスの認証を利用してIDaaSにログインする

OneLoginでは、ツールを入れることでデバイスの認証の”前”にIDaaSでの認証するを実現できますが、業務で使えるレベルかというと少々疑問が残ります。Windows, Mac両対応なのはいいところなんですがね。
Intuneを用いたWeb Authを利用する方法もありますが、どちらもコストと運用に課題が残るため、単純な導入はハードルが高めですかね。

後者のデバイスの認証を利用してIDaaSにログインするという仕組みは多くのIDaaSで採用している方式です。IWA(Windows統合認証)を利用してIDaaSの認証に使うというものです。
ただし、この方法でシングルサインオンはできますが、端末の認証をIDaaSで管理しているわけではありません。
また、ADなどを使っていないといけませんし、ネットワークの制限も受けます。
また、OSの認証をIDaaSで管理するわけではないので、そこを期待する場合は要件をクリアできません。

セキュリティにおける要件

先に記載したデバイスの認証の”前”にIDaaSで認証することでセキュリティは強固になるのか?という部分にフォーカスします。
クラウドサービスに対するアクセスを端末で制限したいという要望は非常によく聞きますが、方向性の違う内容なので割愛します。
ここで守るべき対象は、ローカルに保存されたデータリソースとなります。

OSの認証が突破されてしまえば、ローカルデータにはアクセスし放題となってしまいます。
Windows 10ではWindows Helloなどの生体認証を搭載していたりしますが、生体(顔や指紋認証)を使える端末が限られていることや、PINでもログインできてしまいます。
PINだとショルダーハッキングなどで、突破される可能性があるのでPINコードは設定しないこともできますが、ユーザ側のリテラシに依存する運用は避けたいところです。

そのために、本来セキュリティを向上の施策として理想的なのはOSの認証時にMFA(多要素認証)を利用させることです。

ただし、OS標準以外のもの(例えばOneLogin Desktop)を利用する際には、その仕組みがLDAPなどのレガシーなプロトコルであるが故に、利用するMFAの選択ができない場合があります。
そうすると、全従業員に対してIDaaSの標準的なMFAを使わせるという必要が出てくるためハードルがあがってしまいます。

また、デバイス紛失時などにはIDaaSのアカウント停止運用ができるというメリットはありますが、キャッシュログインが穴になります。
キャッシュログイン自体を無効にすることで、よりセキュアになりますがユーザの利便性を著しく損ないますので、そこまでするのであればWidows Helloを生体のみにする方がまだ現実的ですね。
個人的にはOSの認証をIDaaSにしてもセキュリティはあまり向上しないと思います。

そもそもローカルにデータを持たなければいいんですけどね。そういう意味ではChromeOS + G Suiteはスリープ時にローカルデータを消せるらしいのでいいかもしれないですね。

運用における要件

デバイスのアカウントとIDaaSのアカウントが分離することで出てくるデメリットは2つです。
・利用者が管理するパスワードが増える
・管理者か利用者がアカウントを登録する必要がある

このどちらもが、ローカルアカウントを用いる場合や、ADとIDaaSが連携していない場合に発生します。

これら運用負荷の改善が要件であればOSの認証をIDaaSに変えなくても、IDaaSとADを連携するだけで十分に改善可能です。
ローカルアカウントの場合はAzure AD Joinへの移行をオススメします。

OSの認証にIDaaSを利用するには

ADは運用していない、ADでグループポリシー使ってないよという場合は、安価にOSの認証にIDaaSを利用させる方法があります。
といっても対象OSはWindowsです。Macは Jamf 使いましょう!

IDaaSは何を使ってもかまいません。それにAzure ADを追加します。
Azure ADのライセンスはリッチなものでなくて構いません。無料のやつでも、Office365に付属するものでもいいです。
逆にすでにP2持ってたり、なんならIntuneライセンスも持っているという場合はそのままAzure ADをIDaaSとしてご利用ください。

Azure ADは1つのドメインに1つだけIdp(IDaaS)を設定することができます。Azure ADに認証しに行くとOktaなどのIDaaSにリダイレクトされ、そこでの認証結果により、Azure ADにログインするということができます。

これはWindow 10のデバイスにAzure AD Userでログインする時も同様の動きをします。もちろんIDaaSでMFAを設定していればMFAを要求できますし、モダン認証なので、GUIでMFAのFactorの選択もできます。

Officeライセンスの場合はプランにもよりますが、安いものだとOneLoginにvLDAP($2)とOneLogin Desktop($4)を選択するよりもよっぽど安価で、Officeアプリも使えます。2度目になりますが、Macは Jamf 使いましょう。

ただ、注意点もあります。Windows10のログイン時に毎回IDaaSにリダイレクトされるかというと、そうはなりません。
AzureADではアクセストークンをキャッシュしているため、トークンが切れるまではIDaaSにリダイレクトされず、Windows10とAzure ADの世界でのログインになります。
常時はWindows Helloを使ってログイン、定期的にIDaaSでMFAを使った認証をするといった使い勝手になります。

デバイスの登録情報やログインのログはAzure ADでみます。ここに関してはOneLoginで一つにまとめたほうが管理自体はしやすいかもしれません。

まとめ

「認証だけ」IDaaSで管理したいなら、WindowsはAzure AD MacはJamfを使うのがいいと思います。

ただし、気を付けないといけないのは、認証だけIDaaSで管理していても、ポリシーやデバイスの管理はできないので、それは別で考えないといけません。MDMやネットワーク製品も一緒に考える必要がでてきますので、さらなるIT投資が必要となります。

追記(2020/5/6)

Windowの認証にG Suiteを利用することもできます。注意点は以下

・現時点では利用できるG Suiteのライセンスが限られている
・Windows端末のMDMの枠を利用する

MDMは原則、1デバイスに対して枠が1つしかないので、他のエンドポイントセキュリティ製品とバッティングしてしまう可能性があります。

また、G SuiteがOktaなどのIDaaSに認証委任する構成において、G SuiteのアカウントでChormeOSにログインする場合は、認証をIDaaSで受けることができます。
ChromeOSの認証はIDaaSにリダイレクトさせないこともできますので、そこはお好みでどうぞ。


この記事が気に入ったらサポートをしてみませんか?