2017年4月18日火曜日

今年の de:code はユーザ事例を通して Azure AD 導入の実情をお伝えします

こんにちは、富士榮です。

いつの間にか de:code 2017 まで約1か月となりました。
昨年の de:code ではチョークトークで何でも QA コーナーみたいなセッションを担当しましたが、今年は本職?での株式会社アシックス様の案件事例を通して Azure AD の活用の実際をお伝えします。



これまでも事例をベースにしたセッションはやってきたんですが、実は Azure AD 案件の事例をオープンな場でお話しするのって初めてなんですよね。今回は Azure AD を導入するにあたり Azure Web App や Azure Automation、Express Route など Azure 関連のサービスをそれなりの種類使っていたりしますので、Azure AD 自体の使い方に加えて、その辺りの話も織り交ぜつつグローバル企業におけるクラウド・ベースの認証基盤のあり方や既存環境からのマイグレーションなどについてお話できると良いなぁ、と思っています。

参考)これまでオープンにしてきた IdM 系の事例です。(節操なく色んなベンダの仕事してますね)



どうしても本職絡みだと言えないこともあったりするんですが、今回はなるべく Azure AD の各種技術的な要素が実際の案件ではどのように使われているのか?を皆さんにお伝えすることで、色々とイメージをしてもらえればと思いますので、お手すきの方はぜひお越しください。

あ、2日目の最終コマだったと思います。


尚、今回の de:code ではセキュリティ・トラックが 16 セッションもあり、私の他にも Enterprise Mobility の MVP が大勢出てきてマイクロソフト社員が語れないこと?を語ってくれると思いますので、私自身も非常に楽しみです。

以下、セキュリティ・トラックのセッション一覧です。

セッション番号タイトル担当
SC01DevSecOps on Azure : セキュリティ問題に迅速に対応するためのパイプライン設計MS安納さん
SC02シチュエーション別 Active Directory デザインパターンMVP宮川さん
SC03Active Directory の DR 対策~天災/人災/サイバー攻撃、その時あなたの IT 基盤は利用継続できますか?MVP渡辺さん
SC04あなたのサービスを "ID" で守る! Azure Active Directory の条件付きアクセスの基礎と実装MS松井さん
SC05株式会社アシックス様における Azure AD 導入プロジェクトの実際MVP富士榮
SC06Windows と Azure、2つの Information Protection をディープに解説!MVP国井さん
SC07Azure AD と Ruby で学ぶ OpenID Connect!MVP真武さん(nov)
SC08SDL からビジネスモデルまで IoT セキュリティを俯瞰するMS高橋さん
SC09パッチ待ちはもう古い!Windows 10 最新セキュリティ技術とゼロデイ攻撃攻防の実例MS村木さん
SC10Intune Application Protection を可能にするモバイル アプリ開発MSロバートさん
SC11セキュリティマニアックス ~侵入。ダメ。ゼッタイ。~MS蔵本さん
SC12DevSecOps 時代のセキュリティ人材DIT河野さん
SC13ログ管理で向上させるセキュリティMS山本さん
SC14IoT のセキュリティアーキテクチャと実装モデルMS安納さん
SC15Windows Hello で実現するハイブリッド 生体認証MS小町さん
SC16スパムの脅威から企業を守る!Office 365 で実現するセキュアコラボレーションtwofive末政さん


ちなみに、今年はゴールデンウィーク明けの EIC(European Identity & Cloud Conference 2017)に行こうと思っているので、実はほとんど資料を作る時間がないのが最大の課題です・・・。



2017年4月5日水曜日

Office365管理者は要対応)UPNとProxyAddress重複オプションの強制変更がいよいよ開始

こんにちは、富士榮です。

以前紹介したAzure AD Connectでのディレクトリ同期時にUPNやProxyAddressが重複しないように自動的にサフィックスをつけてくれるオプションがいよいよ全テナントで強制的に有効になるようです。

 以前の紹介記事
 [Azure AD/Office365]管理者は要注意。ディレクトリ同期に関する仕様変更
 http://idmlab.eidentity.jp/2016/09/azure-adoffice365.html

簡単に内容をリマインドしておくと、複数のオンプレミスADから単一のAzure ADディレクトリへ同期したり、オンプレミスのUPN以外の属性(例えばメール属性)をAzure ADのUPNにマッピングするなど属性のユニーク性が担保されない環境で運用を行う際、ディレクトリ同期時にAzure AD側でUPNを自動的に「ユーザ名+4桁のランダム数値@デフォルトドメイン名」という様に変更する、というオプションが追加されました。
(UPN版とProxyAddress版の2つのオプションがあります)

このオプションが有効だとディレクトリ同期時の重複エラーを抑制することはできますが、勝手にUPNが書き換わってしまうのでオンプレミスのディレクトリの状態によっては若干困ることがあるので、昨年発表された段階では強制的に有効化されることはなく、しばらくは猶予期間が作られました。

しかし、この4月から遂に強制変更が開始されるようです。

4月1日前後に以下のメールが管理者宛てに来た場合は、メールに記載の日程から強制的に有効化されます。私のテナントの場合は4/19から強制有効化されるようです。
(以外と急でした・・・)

タイトル:New Identity Synchronization Feature Being Enabled - Duplicate Attribute Resiliency
差出人:MSOnlineServicesTeam@microsoftonline.com




急ぎ、自社のディレクトリ構成を確認してUPNが急に変わった~~~というようなパニックに陥らないように準備しておきましょう。




2017年3月29日水曜日

[Azure AD+PingAccess]Basic認証のあるバックエンドサイトへアクセスする

こんにちは、富士榮です。

前回はAzure ADとPingAccessの組み合わせで、PingAccessのバックエンドに配置したHTTPヘッダ認証のサイトをAzure AD Web Application Proxy(Azure AD WAP)で公開する構成を紹介しました。

PingAccessは色々と器用なツールなので、既存のアプリケーションがBasic認証だった場合にも「ある程度」対応ができます。今回はPingAccessのバックエンドのサイトがBasic認証で構成されている場合の設定を紹介します。

尚、「ある程度」と書いたのはBasic認証がユーザのIDとパスワードをエンコードしたものを認証ヘッダにつけるという仕組みである以上、Password Vaultingをしないといけないので、固定のIDとパスワードしか投げ込むことしかできず、個別のユーザ認証とはならない為です。

では、早速。

◆サイトを用意する

何はともあれ、Basic認証を要求するサイトを作ります。今回はIISで構成しました。
PingAccessのサーバからアクセスしてBasic認証が要求されることを確認しておきます。


◆PingAccessのSite Authenticatorを作成する

SitesメニューよりSite Authenticatorを作成します。

TYPEにBasic Authentication、USERNAMEとPASSWORDにBasic認証に使うユーザ名とパスワードを設定します。
ここが微妙なところで、個別のユーザ毎ではなく、Authenticator単位での設定しかできないので、実際のサイトへアクセスするユーザ名とパスワードが共通になってしまいます。

◆SiteにAuthenticatorを紐づける

Authenticatorを作ったらSiteに紐づけます。既存サイトであれば構成を編集して、新規サイトなら追加をして、SITE AUTHENTICATORSに先に作成したSite Authenticatorを設定します。

その他の設定は前回行ったものと同じなので、詳細は省略します。

◆Azure AD WAP経由でアクセスする

Azure AD WAP、PingAccessを経由せずにアクセスするとBasic認証が要求されましたが、Azure AD WAPを経由してアクセスするとBasic認証はかからずにサイトへログオンできます。

Webサーバのログを見ると、先ほど設定したユーザでWebアクセスがあったことがわかります。



今回はここまでです。せっかく色々な機能があるPingAccessなので、上手に連携していけば既存のオンプレミスのアプリケーションのAzure ADへ対応させる新たな構成の選択肢となってくる可能性もありますので、今後も目が離せませんね。

2017年3月27日月曜日

[Azure AD]PingAccess連携でオンプレ資産へのアクセスを拡張する

こんにちは、富士榮です。

待ちに待ったPingAccess+Azure AD連携のパブリック・プレビューが始まりました。
昨年のTechSummitで少しだけ紹介しましたが、当時はプライベート・プレビュー段階だったのでお見せ出来ず。。。

アナウンス
 公式blog
 PingAccess for Azure AD: The public preview is being deployed!
 https://blogs.technet.microsoft.com/enterprisemobility/2017/03/22/pingaccess-for-azure-ad-the-public-preview-is-being-deployed/


簡単に言うと、Azure AD Web Application Proxy(Azure AD WAP)を経由してPingAccessのサーバをインターネットへ公開、PingAccessのリバースプロキシ配下のアプリケーションへアクセスを可能にする、という構成が取れるようになります。

このことにより、これまでAzure AD WAPではバックエンドのアプリケーションは統合Windows認証が前提だったのが、HTTPヘッダ認証のアプリケーションなどPingAccessが対応している認証方式のアプリケーションであれば外部に公開することが出来るようになります。


とりあえず今回はHTTPヘッダ認証を使ったアプリケーションとの連携を公式ドキュメントの手順+αでやってみたいと思います。
(ちなみに公式ドキュメントが一部間違っているので・・・)

参考手順はこちら
 Azure AD側
 https://docs.microsoft.com/en-us/azure/active-directory/application-proxy-ping-access

 PingAccess側
 https://docs.pingidentity.com/bundle/paaad_m_ConfigurePAforMSAzureADSolution_paaad43/page/pa_c_PAAzureSolutionOverview.html


では早速。

◆Azure AD WAP経由で公開するオンプレミスアプリケーション定義を作成する

通常のAzure AD WAPでオンプレミスアプリケーションを公開するのと同じ手順で、PingAccessサーバを公開します。この段階ではPingAccessはまだダウンロード・インストールはしていないので内部URLなどは適当なものを設定しておき、あとで修正しても問題ありません。

Azure ADポータルよりエンタープライズアプリケーションの登録を行います。アプリケーションの種類は「オンプレミスのアプリケーション」を指定します。

内部URL、公開URL、認証方式などの設定を以下の通り行います。

  • 内部URL
    • Azure AD WAP ConnectorからアクセスできるPingAccessサーバのURLです。今回はPingAccessとConnectorを同じサーバにインストールしたので、https://localhost:3000としています。
    • 尚、公式ドキュメントでは内部URLにもアプリケーションパスを追加する、とありますが、Azure ADで認証された後、認可コードをPingAccessサーバのコールバックエンドポイントへGETで渡す必要があるので、アプリケーションパスを追加するとコールバックエンドポイントへアクセスできず、うまく動かないのでパスを追加してはいけません。
    • また、PingAccessサーバがhttpsで動いているので、Connectorサーバからのアクセス時に証明書エラーが起きないように、一旦ConnectorサーバでPingAccessサーバへアクセス、証明書をインストール、エラーが起きない状態にしておく必要があります。
  • 公開URL
    • ここは適当に設定します。後で使うので値は覚えておきましょう。
  • 事前認証
    • Azure ADで認証するので当然Azure ADを選択します。
  • ヘッダーのURL変換
    • 「いいえ」を選択します。
  • コネクタグループ
    • PingAccess用のAzure AD WAP Connectorが属しているコネクタグループを選択します。
こんな感じです。


次にシングルサインオン設定を行います。
これまで出てこなかった、「Header-based Sign-on」が認証方式として選択できるようになっているので、これを設定します。
※ちなみにテナントによっては出てこない場合があるので、その場合はPreview版のAzure ポータルからAzure ADにアクセスしてみてください。私の環境では一度Previewポータルで設定をしたら次からは現ポータルでも出てくるようになりました。
 Preview版ポータルは
 もしくは、
 あたりからアクセスできます。

Header-based Sign-onを選択するとPingIdentityのロゴとともに、PingAccessのダウンロードサイトへのリンクが出てきますので、アクセスします。

リンクを開くとPingIdentityの登録サイトへ行くので名前などを登録します。

登録するとメールが届き、その中にモジュールとライセンスのダウンロードページへのリンクが入っているのでアクセスします。リンクは7日間有効だそうです。

ここで各プラットフォーム用のモジュールとライセンスのダウンロードができます。
ちなみに、普通のPingAccessのサイトからダウンロード(現時点では4.2.2)できるモジュールとこのサイトからダウンロードできるモジュール(4.3.0BETA)は別物なのでここからダウンロードしてください。(そのうち統一されるとは思いますが)

◆PingAccessがAzure ADからid_tokenをするためクライアント登録を行う

PingAccessはAzure ADから渡されたid_tokenの中のClaimをヘッダにマッピングするだけなので、先ほど作成したアプリケーションにscopeの設定、client_idとclient_secretの取得をしておく必要があります。

先ほどはエンタープライズアプリケーションの設定メニューでしたが、この設定を入れるにはアプリの登録メニューから操作を行う必要があります。
アプリの登録メニューから先ほど作成したエンタープライズアプリケーションを探して開きます。

まずはAPIアクセスの許可です。
  • 対象API
    • Windows Azure Active Directory
  • 必要なスコープ
    • アプリケーションへのアクセス許可
      • Read and write all applications
    • 委任されたアクセス許可
      • Sign in and read user profile

次にclient_secretの作成です。Azure AD用語ではキーですので開いて作成・保存します。

保存するとキーが表示されるので、控えておきます。
同様にclient_idはアプリケーションIDなのでこの値も、そしてディレクトリID(Active Directoryのプロパティから確認できます)を控えておきます。

ここまででPingAccessの設定に必要な情報はそろいました。
尚、公式手順を見るとReply UrlにAzure AD WAPの外部URLが設定されていることを確認し、必要に応じて手動設定すること、という説明がありますが特に問題なく自動設定されました。

◆PingAccessのインストールとライセンス設定

いよいよPingAccessのインストールと設定です。先ほどのPingIdentityのページよりダウンロードしたモジュールを使います。
今回はWindows Server 2016のサーバにAzure AD WAP Connectorと同居する形でインストールしました。

MSIモジュールを実行すると以下の通りインストールが走ります。基本的には次へ、次へでOKです。ちなみに事前にJRE1.8以降がインストールされておりJAVA_HOMEが環境変数に設定されている必要があります。

とりあえずスタンドアロン版にしていますが、プロダクション環境ではクラスタを作ることになると思います。







取り敢えずインストールは簡単ですね。
次は設定を行います。

まずはブラウザで管理コンソールへアクセスします。デフォルトインストールだと
 https://サーバ:9000/
でアクセスできます。

初回アクセスの場合、ライセンスのアップロードが求められるので先にダウンロードしたライセンスファイル(zip)を解凍して出来るlicファイルを選択してアップロードします。

上手くライセンスが登録されると、管理者でログインが求められます。
初期状態ではID:Administrator、パスワード:2Accessでアクセスできます。

初回ログインが成功するとパスワード変更が求められますので適当に変更しておきましょう。

これでようやく管理コンソールが開きます。


◆PingAccessとAzure ADの連携設定、バックエンドアプリへのプロキシ設定を行う

いよいよAzure ADとの連携設定です。

まず、SystemメニューよりTOKEN PROVIDERを開きます。

流石専用版、ISSUERに最初からAzure ADのURLが固定で入っているので、先ほど確認したディレクトリIDを設定してSAVEします。

次に、VirtualHostの設定です。要するにAzure AD WAPからアクセスが来た場合の挙動の設定をするための入れ物です。

HOSTに先ほどAzure AD WAPの設定の時に指定した外部URLのホスト名パートを設定し、PORTには443を設定しておきます。

次は、WEB SESSIONの指定をします。Azure ADから取得したid_tokenを使ってセッションを生成するので、先に取得したclient_id、client_secretはここで使います。


NAMEは適当に、COOKIE TYPEはSigned JWT、AUDIENCEはCookie名になるのでそれなりの値を設定します。

次に先ほどAzure ADで取得したclient_idとclient_secretを指定します。


次は、id_tokenから取得したClaimをヘッダへ変換するためのマッピング設定を行います。IDENTITY MAPPINGから設定していきます。

TYPEにHeader Identity Mappingを設定して、、

id_tokenの中のClaim名とヘッダ名をマッピングしていきます。


ここまででAzure ADとの連携部分は終わりなので、後はバックエンドサーバの設定をしていきます。まずはSite設定です。Sitesメニューを開き、Add Sitesをクリックします。

ここが実際のバックエンドサーバのアドレスやURLを入れる部分なので、今回は手元にあったCentOSのApache CGIを指定してみたいと思います。
適当な名前を設定して、TARGETSにサーバアドレスを指定します。


最後にここまでに設定してきた内容を組み合わせてPingAccess上でApplicationとして定義を行います。Applicationsメニューを開き、Add Applicationをクリックします。

名前は適当に。CONTEXT ROOTにはリバースプロキシとしてのパス設定なので、バックエンドアプリケーションのパスを指定します。今回はcgiを動かしてみようと思うので、/cgi-binを公開します。

後は、VIRTUAL HOST、WEB SESSION、SITEなどここまでに定義したものを設定していきます。

同様にIDENTITY MAPPINGも選択し、最後に「ENABLED」にチェックを入れてSaveします。

これで設定は完了です。

早速テストしてみましょう。

◆動作確認

Azure AD WAPに設定した外部URLに、今回PingAccessで公開しているバックエンドサーバのパスを付けたものへアクセスしてみます。
 今回だとこんな感じです。
 https://pingaccess-pharaoh.msappproxy.net/cgi-bin/

すると、Azure AD WAPに事前認証として指定した通り、Azure ADのログオンがおこなわれ、PingAccessからAzure ADへのアクセスに関する許可が求められます。(初回のみ)

そして、うまくいくとPingAccess配下のアプリケーションが表示され、ヘッダにマッピング設定した通りに値が表示されます。

もちろんテスト前にAzure ADでアプリケーションへユーザの割り当てをしておいてください。



今回はPingAccessのリバースプロキシ配下のアプリケーションへHTTPヘッダでAzure ADのClaimを渡すというシナリオだったので、mod_auth_openidcとmod_proxyを使って同じような環境は割と簡単に作れるとは思います。
 参考)CentOS+Apacheの認証をAzure AD/OpenID Connectで行う
   http://idmlab.eidentity.jp/2017/01/centosapacheazure-adopenid-connect.html

PingAccess連携を使うメリットは既にPingAccessで構成されたアプリケーション資産が存在していたり、Agent型でPingAccessが構成されているような場合に最大化されます。また、PingAccess自体が他のWAM製品との連携(というか他製品のフリをする)が得意な製品なので、Oracle Access ManagerやIceWallなどが既存で入っている環境をAzure ADへシームレスに移行する際には本領を発揮することになると思います。

このあたりのシナリオもまた検証してみたいと思いますので、またそのうち公開するかも知れません。




2017年3月21日火曜日

[小ネタ]NAT構成のVMに構成されたAD FSへiOSデバイスを登録する

こんにちは、富士榮です。

今回は完全に小ネタというか自分用のメモです。

普段、BootcampなMacbook AirにWindows 10を入れ、その上でVMware Workstationを動かして、AD FSやMIMを動かして検証してるんですが、VMやAzureだけでクローズできないネタを検証する場合です。

具体的にはiOSやAndroidデバイスなどをAD FSへデバイス登録してデバイス認証をしたい場合、以下が困ります。
・JailbreakしていないiOSだとhosts登録が出来ない
・色々と事情があってVMをNAT構成で動かしているので母艦PC以外からVMへアクセスできない

ということで、対処してみます。

と、言ってもやることは母艦にApacheを立ててForward Proxyにするだけなんですが。

◆Apacheをダウンロードして構成する

Apacheの本家からWindows用のbinaryのダウンロードは出来なくなっているので、本家からリンクされているサイトからダウンロードをして使います。
 http://httpd.apache.org/docs/current/platform/windows.html#down

母艦がWindows 10 Pro x64なので、64bit版をダウンロードしてきました。バージョンは現時点の最新版な2.4.25です。

zipアーカイブを解凍したら少々コンフィグをいじくります。(conf\httpd.confを編集します)
ポイントは、

  1. パスを合わせる
  2. Proxyに必要なモジュールをロードする
  3. Forward Proxyとして構成する
  4. ServerNameをつける

の4点です。

では順番に。

1.パスを合わせる

 変更箇所はServerRoot、DocumentRoot、ScriptAlias、cgi-binのディレクトリ設定の4か所です。単にForward Proxyとして使うだけなので変更しなくても問題はありませんエラーが出るので。以下の5行が変更対象です。今回、C:\Tools\Apache以下にモジュールを展開したので環境に合わせて編集します。
ServerRoot "C:/Tools/Apache/Apache24"
DocumentRoot "C:/Tools/Apache/Apache24/htdocs"

    ScriptAlias /cgi-bin/ "C:/Tools/Apache/Apache24/cgi-bin/"

2.Proxyに必要なモジュールをロードする

 必要なモジュールのLoadModule行のコメントアウトを外します。今回AD FSを使うのでhttpsのフォワードも必要なのでmod_proxy_connectも使います。
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so

3.Forward Proxyとして構成する

 非常に雑な構成ですが、httpd.confの最後に以下を追記します。

  ProxyRequests On
  ProxyVia On
  Listen 8080
  AllowCONNECT 443
 
    Order deny,allow
    Deny from all
    Allow from all
 

4.ServerNameをつける

 これはしなくてもいい設定ですが、Apacheの起動時にワーニングが出るのでとりあえず設定しておきます。

ServerName hoge:80

取り敢えずここまで設定したらOKなので、起動しておきます。
私の場合は検証したい時だけ立ち上げれば良いので、サービス化はせずにコマンドプロンプトから直接起動します。

binディレクトリ配下でhttpd.exeを起動するだけです。


◆母艦からアクセスできるようする(hostsファイルの構成など)

母艦経由でVMへアクセスさせたいので、まずは母艦からアクセス出来るようにネットワークを構成をしてあげる必要があります。

多くの場合、適当な名前(.localとか)でドメインを構成していたりするので、母艦のhostsファイルを使って適切にアクセスできるように構成する必要があります。

後は、念のため母艦からAD FSへアクセスできることを確認しておきましょう。


◆iOS側のProxy設定をする

最後にiOSのWifi設定でProxyサーバに母艦PCを指定します。
尚、当然の事ながら母艦PCへの8080ポートの通信をWindows Firewallで開放しておく必要があります。

iPhoneの設定からWifiを開き、母艦PCと同じアクセスポイントへ接続していることを確認したら、母艦PCのIPアドレスとProxyサーバとして指定した8080番を指定します。


設定はこれで終了です。

◆DRSへアクセスしてデバイス登録する

この状態でiPhoneからAD FSのデバイス登録サービス(DRS)へアクセスして、プロファイルがインストールされるか確認してみます。

DRSのアドレスは
 https://ADFSServer/EnrollmentServer/otaprofile
ですが、当然インターネットにしか繋がっていないiPhoneからVMで動いているAD FSへアクセスは出来ず、DRSへ到達できません。

しかし、今回母艦に立てたProxyを経由することでVM上のAD FSへアクセスでき、無事にプロファイルがインストールできます。



当然、デバイスクレームの取得もできるので、手元でアクセス制御のテストも行うことが出来ます。



まぁ、Azure上にIaaSを立ててインターネットからもアクセス出来るようにすればいいんでしょうが、iOSからアクセスできるようにちゃんとDNS登録が必要だったり、特にDRSの場合はenterpriseregistrationの名前が解決できる証明書を用意しなければいけなかったりするので、手元で済ませられれば手軽なのでこういう方法もありかな~と思っています。

2017年3月7日火曜日

[続報]Office365管理者は要対応。外部共有により不要なアクセス権が付与される

こんにちは、富士榮です。

先日のポストでOffice365の外部共有を有効にした場合に意図しないアクセス権限がゲストユーザに付与されてしまう、という注意喚起をさせていただきました。

 Office365管理者は要対応。外部共有により不要なアクセス権が付与される
 http://idmlab.eidentity.jp/2017/01/office365.html


ポスト後も米国マイクロソフトの開発チームへフィードバックをしていたのですが、他の国でも同じ意見の管理者・技術者の方も多く、Azure Portalのディレクトリ構成情報へのアクセスに関するセキュリティ設定が追加されました。

このことにより、前回紹介した条件付きアクセスを使いAzure Portalへのゲストユーザのアクセスを拒否する対策(Azure AD Premium P1ライセンスが必要)を行う必要がなくなりました。

ただ、アクセスパネル経由のアクセスでディレクトリを切り替えることによりAll Usersへ割り当てられたアプリケーションが見えてしまったり、認可設定が不適切なアプリケーションへのアクセスを防ぐことはできないので、こちらは引き続き対応が必要です。


では、早速Azure Portalでディレクトリ構成情報へのゲスト・アクセスを防ぐ方法を紹介します。ちなみに今回さらに新たな設定項目が追加されており、自ディレクトリ内のユーザでも非管理者によるアクセスを防ぐことも可能になっています。

◆ゲストユーザによるディレクトリ構成情報へのアクセスを防止する

まずはゲストユーザがディレクトリ構成情報へのアクセスを防止するための設定です。

管理者がAzure Portalへアクセスし、Active Directoryを開き、[ユーザー設定]を開くと、外部ユーザの設定の中に「ゲストのアクセス許可を制限する」という設定項目が追加されています。デフォルトで[はい]が設定されており、既定でアクセス制限が有効な状態となっています。


同様に管理ポータルの設定に「Azure AD管理ポータルへのアクセスを制限する」という項目も追加されており、こちらの設定では非管理者ユーザが自ディレクトリであってもディレクトリ構成情報へアクセスすることを防ぎます。(こちらの初期値は[いいえ]なので必要であれば設定変更を行います)こちらは後述します。


前回のポストをした際は初期状態ではゲストユーザがAzure Portal経由でディレクトリ構成情報(ドメイン情報など)へアクセスできましたが、現在は初期状態でアクセス制限がかかっているため、同じようにアクセスすると以下の様なエラーが表示されてディレクトリ構成情報を開くことが出来ません。(Azure Portalまでは開きます。Active Directoryメニューを開くとこの状態になります)


前回紹介した条件付きアクセス機能を使ってAzure Portal自体へのアクセス拒否をした場合は以下のように認証後すぐにエラーが出るので若干動作が異なります。


◆非管理者ユーザによるディレクトリ構成情報へアクセスを防止する

次は、非管理者ユーザがディレクトリ構成情報へアクセスできないように設定を行います。先に書いた通り、今度は管理ポータルの項目の「Azure AD管理ポータルへのアクセスを制限する」を[はい]に設定します。


この状態で非管理者でAzure Portalへアクセス、Active Directoryを開くと先のゲストユーザによるアクセスの際と同様に以下のエラーが表示されアクセスがブロックされます。



◆とりあえずは安心?

これで一応最低限のLeast Privilegeの法則は守られてきていますが、冒頭にも述べた通り、アクセスパネル(https://myapps.microsoft.com)へのアクセスによりAll Usersに割り当てられたアプリケーションは見えてしまい、かつ認可設定が不十分だと使えてしまうので、こちらは引き続き注意をして行く必要があります。

日々設定項目が進化していくAzure ADですが、項目が増えていき複雑性が増していくことにより、自社にとって最適な設定が変化していくことにもなりますので、管理者の方は継続的にフォローアップをしていく必要がありそうです。


◆最後に告知

前回のポストや本ポストに記載したOffice365やAzure AD管理者が考えるべきセキュリティ設定について、3/11に開催されるOffice365勉強会でお話しします。

 案内・告知
 Japan Office365 User Groupのページ
 http://jpo365ug.com/o365-meeting/meeting-18/

今週末の開催となり、既にキャンセル待ちの状態ですがよろしければどうぞ。