「社用端末（証明書）」を含むセキュリティープロファイル作成時の確認事項

サインオン時の証明書の確認は、セキュリティープロファイルの優先順位により証明書が必要なタイミングを自動で判断するようになります。
そのため、「社用端末（証明書）」を含むアクセス制限ルールを設定しているセキュリティープロファイルでは、ルールの順番や、アクセスする端末タイプによってサインオンができなくなる場合があります。

本記事では「社用端末（証明書）」のセキュリティープロファイルを作成する際、どのような点に注意して作成したら良いのか、また既に作成済のセキュリティープロファイルに対してはどのような対応が必要なのかを説明します。

確認事項

「社用端末（証明書）」の順番

「社用端末（証明書）」は一番最後のルールに設定していただきます。
「社用端末（証明書）」のルールが、同じ端末タイプ（PC／スマートデバイス）の他のルールより上に設定されていると、「社用端末（証明書）」以外のルールでは判定が行われない場合があります。
次項の設定例では対処策もあわせてご案内します。

「個人端末（ブラウザー）」との併用

同じ端末タイプ（PC／スマートデバイス）で「社用端末（証明書）」と「個人端末（ブラウザー）」のルールを併用して利用する際、個人端末（ブラウザー）で利用する端末で端末登録を実施し、登録可能端末を全て使用した後に、社用端末（証明書）の運用を開始します。

クライアント証明書を使ってサインオンする端末にCookieが発行されて、証明書を利用せずに個人端末（ブラウザー）でサインオンできてしまうことを防ぐための運用方法です。詳細は「クライアント証明書とCookieとの併用について」でご説明します。

設定例：「IPアドレス」との組み合わせ（NGパターン）

• ルール１：社用端末：PC（証明書）
• ルール２：IPアドレス　※PCからアクセス

CloudGate UNOサインオン時に必ずクライアント証明書の確認が行われ、IPアドレスの確認が行われなくなります。そのため、許可IPアドレス内・外関係なく、クライアント証明書がインストールされていない端末ではサインオンができなくなります。

対処方法

「ルール１：「社用端末（証明書）」をアクセス制限ルールの最下部に設定します。

• ルール１：IPアドレス　※PCからアクセス
• ルール２：社用端末：PC（証明書）

ルールの順番変更により、ルール１の「IPアドレス」の判定が行われたあと、ルール２の「社用端末（証明書）」の判定が行われるため、「IPアドレス」がNG（許可IP以外からのアクセス）と判定された場合に、「社用端末（証明書）」の判定が行われるようになります。

設定例：「個人端末（ブラウザー）」との組み合わせ（OKパターン）

• ルール１：社用端末：PC（証明書）
• ルール２：個人端末：スマートデバイス（ブラウザー）

端末タイプが社用端末（証明書）と異なるため、アクセス制限ルールの順番によるサインオンエラーは発生しません。

設定例：「個人端末（ブラウザー）」との組み合わせ（NGパターン）

• ルール１：社用端末 PC（証明書）
• ルール２：個人端末 PC（ブラウザー）

CloudGate UNOサインオン時に必ずクライアント証明書の確認が行われ、「個人端末（ブラウザー）」の確認が行われなくなります。

例えば「端末A」は社用端末（証明書）、「端末B」は個人端末（ブラウザー）で運用をしたい場合、「端末B」では個人端末の登録まで進まないため、Cookieを発行することができずサインオンができません。

対処方法

以下の２つの操作を行います。

1.「ルール１：「社用端末（証明書）」をアクセス制限ルールの最下部に設定します。

• ルール１：個人端末 PC（ブラウザー）
• ルール２：社用端末 PC（証明書）

2.個人端末（ブラウザー）で利用したいブラウザから端末登録を行った後にクライアント証明書がインストールされた端末でサインオンします。※すでに端末登録済の場合はこちらの操作は不要です。
・参考「クライアント証明書とCookieとの併用について」

対処方法（補足）：スマートデバイスで他社製アプリをご利用の場合

スマートフォンの他社製アプリをご利用で、サービスによってクライアント証明書とCookieを使い分けている場合、アクセス制限ルールの順番変更以外にも「認可サービス」を利用することで、他社製アプリにCookieを発行することが可能になります。(SP Initiated SSOタイプのサービスのみです）

設定例：「Chrome OS」との組み合わせ（NGパターン）

• ルール１：社用端末：PC（証明書）
• ルール２：Chrome OS

CloudGate UNOサインオン時に必ずクライアント証明書の確認が行われ、Chrome OSでの確認が行われなくなります。そのため、クライアント証明書がインストールされていないChromebookなどのChrome OS端末ではサインオンができなくなります。

対処方法

「社用端末（証明書）」のアクセス制限ルールをセキュリティープロファイルの最下部に設定します。

• ルール１：Chrome OS
• ルール２：社用端末：PC（証明書）

ルールの順番変更により、ルール１の「Chrome OS」の判定が行われたあと、ルール２の「社用端末（証明書）」の判定が行われるため、「Chrome OS」がNGと判定された場合に、「社用端末（証明書）」の判定が行われるようになります。

クライアント証明書とCookieとの併用について

1つのセキュリティープロファイルに、同じ端末タイプの「社用端末（証明書）」のルールと「個人端末（ブラウザー）」のルールを設定する場合、個人端末登録を行い、登録可能端末を全て使用している状態にしてからクライアント証明書がインストールされた端末でのサインオンを行う必要があります。

＜設定例＞

• ルール１：個人端末 PC（ブラウザー）登録可能端末「１」
• ルール２：社用端末 PC（証明書）

こちらのプロファイルが適用されているユーザーは、端末Aで証明書を利用、端末Bで個人端末（ブラウザー）での利用を想定しています。

この場合、端末Aで最初にサインオンすると、端末AにCookieが発行され、クライアント証明書ではなくCookieでのサインオンができてしまいます。またこの操作により、個人端末（ブラウザー）の残り登録可能端末数が「0」になった場合、本来Cookieを発行して運用するはずだった端末Bで端末登録できず、サインオンができない状態となります。

Cookieを発行したい端末で最初に端末登録を行う

最初に端末Bでサインオンを行い、個人端末の登録が完了してから端末Aでサインオンします。それにより、端末Bに端末登録が行われます。以降のサインオンはCookieによる端末制限でサインオンできます。
また、端末Aには証明書がインストールされているため、社用端末（証明書）でサインオンできます。

既存のセキュリティープロファイルで確認すること

既に設定済のセキュリティープロファイルのアクセス制限ルールにて、社用端末（証明書）と個人端末（ブラウザー）を併用している、かつ端末タイプ（PC／スマートデバイス）が同じ場合は、「社用端末（証明書）」のルールをアクセス制限ルールの最下部に移動する必要があります。

こちらの表では、ルール１とルール２にそれぞれ設定している端末タイプ（PC／スマートデバイス）によって、社用端末（証明書）の順番を最下部に変更する必要があるか、いくつか例を挙げて紹介しています。既に設定済みのアクセス制限ルールを確認する際にご参考ください。