ADでまとめて参照できるようになります。このようなログは不正アクセスの検出に役立つだけでなく、様々な法令に基づいて証跡を保持しなければならないようなケースにおいても有効です。ADのログの参照方法や保持方法について解説します。Directory]より確認できます。Directory]-[サインイン]よりそれぞれ参照します。[監査ログ]では、管理作業のジャンルやその操作の結果(成功・失敗)、対象となるユーザーなどを選択し、フィルターできます。Users」というサービス名を選択すれば、該当のログだけが表示されます。特定のログはクリックすると、その詳細を参照でき、日付、アクティビティの種類(どのような操作を行ったか)、状態(成功・失敗)などを確認できます。万が一、不正アクセスが疑われるような事象があった場合、監査ログを参照することで、その事象の確認ができるようになります。ちなみに、下の画面ではゲストユーザーを削除したことを表しています。AD経由でアクセスするクラウドサービスへのアクセス制御を行う方法について解説しました。OS種類や場所、ドメインに参加しているか、などデバイスの状態に基づいてアクセス制御できることを確認しました。今回は、もうひとつの条件付きアクセスを制御する方法として、多要素認証を活用したアクセス制御方法についてみていきます。多要素認証とは、複数の認証要素を利用して本人確認を行う方法で、通常使われるユーザー名とパスワードに加えて「別の要素」を利用して本人確認を行います。「別の要素」として利用する方法には、主に次の方法があります。Android用のアプリで、それぞれのストアからダウンロードできるので、事前にユーザーのスマートフォン/タブレットにインストールしておいて利用します。インストール後に多要素認証を行うユーザーを登録すると、次回から多要素認証が必要なタイミングで下の図のような通知が表示されます。AD経由でアクセスするクラウドサービスへのアクセス制御を行う方法について解説しました。具体的にはOS種類に基づいてアクセス制御を行う方法を解説しましたが、そのほかにも様々な条件をもとにアクセス制御ができるので、今回はその中でもニーズが高い、会社支給のデバイスからアクセスしたときだけを許可する、という設定についてみていきます。前回のおさらいですが、条件付きアクセスではユーザー/グループ、クラウドアプリ、条件をそれぞれ設定し、すべての条件に合致した場合に拒否する、または条件付きで許可する、という設定を行うものでした。前回は「WindowsまたはiOS以外のOSからのアクセスを拒否する」という設定を行いましたが、その場合、条件で「WindowsまたはiOS以外のOS」、許可/拒否の項目で「拒否」という設定を行いました。条件付きアクセスのおさらいを踏まえて今回は「会社で支給しているデバイスからアクセスした時だけ許可する」という設定を行います。このような条件を設定する場合、最初に「会社支給のデバイス」を定義しなければなりません。条件付きアクセスでは、次の2つの方法で「会社支給のデバイス」を定義できます。どちらの場合も個人所有のデバイスであれば、これらの条件に当てはまることはないと思います。会社支給のデバイスとしましょう、と定義しています。これらの設定は条件付きアクセスの許可/拒否を設定する画面から[アクセス権の付与]を選択して行います。参加済みのデバイスが必要]を選択します。ADにサインインするだけでクラウドサービスへのアクセスが実現するシングルサインオンの設定について解説をしました。Connect/OAuth2.0を使う場合は[承諾]ボタンを押せばアクセス許可の割り当てすら不要でした)。ところが、クラウドサービスへのアクセス制御となると、いつでも、どこからでもアクセスできてしまうというセキュリティ上の課題があるため、単純にユーザー名とパスワードが正しければ無条件にアクセスしても良い、などとすることはできないでしょう。ADではクラウドサービスへのアクセスに追加の条件を設定し、その条件をクリアしたユーザーだけがアクセスできるように制御する「条件付きアクセス」と呼ばれる機能を提供しています。条件付きアクセスでは、クライアントがどこからアクセスしているか?や、クライアントデバイスのOSが何であるか?など、ユーザーアカウントを利用するデバイスの状態をベースにアクセス制御を行います。具体的な処理フローは次の通りです。条件付きアクセスでは、設定を適用するユーザーとグループ、クラウドアプリ(クラウドサービス)を最初に決定し、その後、クラウドサービスへのアクセス条件と許可/拒否を設定します。それでは、具体的な設定方法を確認していきましょう。Directory]から[条件付きアクセス]をクリックして行います。[条件付きアクセス]画面では[新しいポリシー]をクリックして、ルールを作成します。ポリシー作成画面では、最初にポリシーの名前、対象となるユーザー/グループ、クラウドアプリを選択します。ここでは、前回紹介したWebアプリケーションへのアクセスに条件付きアクセスを使ってアクセス制御設定をします。続いて、ポリシーでは条件を設定します。ここでは「WindowsまたはiOS以外のすべてのOS」という条件を設定します。OS種類の設定は[条件]-[デバイスプラットフォーム]を利用します。ADにサインインするだけでクラウドサービスへのアクセスが実現するシングルサインオンの設定について解説をしました。ADで認証させたいというニーズも出てくることでしょう。ADとWebアプリケーションの関連付けを行い、PaaS型クラウドサービスとの間でシングルサインオンを実現する方法について解説します。ADを関連付けていきます。Serviceではアプリを追加すると、Webアプリケーションにアクセスする際に利用する認証サービスを選択できるようになっています。ADにサインインするだけでクラウドサービスへのアクセスが実現するシングルサインオンの設定について解説をしました。ADとクラウドサービスの関連付けを行う方法の第2弾として、SAMLプロトコルをサポートしないSaaS型クラウドサービスとの間でシングルサインオンを実現する方法について解説します。ADにキャッシュさせておき、クラウドサービスにアクセスするタイミングになったときに自動的に提示することで、シングルサインオンを実現します。ADとクラウドサービスの関連付け方法についてみていきます。ADと関連付けします。アプリケーション]を使います。ADを利用する目的はクラウド上のアプリケーションへの認証・認可を一元化することにある」という趣旨の話をしました。現在、多くの企業で抱える課題に、企業で利用するクラウドサービスにアクセスするごとにユーザー名とパスワードを入力しなければならないというものがあります。ADで一度認証を行うだけで、それぞれのクラウドサービスにアクセスするときに毎度ユーザー名とパスワードを入力しなくてもよい、という解決策を提供してくれるという話でした。SaaSの3種類のクラウドサービスのうち、どれを利用するかによって関連付けの方法は異なるのですが、ここではSaaSのケースを取り上げて具体的な関連付けの方法について解説します。ADに関連付ける場合、シングルサインオン用のプロトコルであるSAMLと呼ばれるプロトコルが利用できます。ADが発行するトークンと呼ばれるデータを提示することでクラウドサービスへの認証・認可を済ませる、ということを行います。ADに既にサインインしていれば、クラウドサービスへのサインインが要らなくなる、つまり「シングルサインオン」が実現するのです。ADとクラウドサービスを関連付け、クラウドサービスへのシングルサインオンを実現するための手順を見てみたいと思います。PowerShellコマンドレットを使って作成する方法をみてきました。ADディレクトリの作成方法についてみてきました。Directoryの時と同じように続いてユーザーとグループを作成します。そこで今回はユーザーとグループを効率よく管理するための方法について見ていきます。ADのユーザーとグループの作成方法はGUIの画面から作成することです。具体的な操作も交えながら、その特徴について見ていきます。ADでは「ディレクトリ」と呼ばれる単位で管理を行います。Directoryで言うところの「ドメイン」に当たるものだと思ってもらえれば、分かりやすいと思います。ADディレクトリ」という呼び方をするようです。実際にはディレクトリとドメインの言葉は、区別せずに使ってしまうことが多いようです。いう違いがあるという認識をしていただいた上で、どちらでも皆さんにとって使いやすい言葉を選択してください。