Salesforce ログイン時間：セキュアなアクセス管理のためのアーキテクトガイド

日付:

背景と応用シナリオ

Salesforce アーキテクトとして、我々の責務は単に機能的なソリューションを設計するだけでなく、プラットフォーム全体のセキュリティ、コンプライアンス、スケーラビリティを確保することにあります。その中で、Login Hours（ログイン時間）は、シンプルながらも非常に強力なアクセス制御ツールです。これは、特定のユーザーが Salesforce にログインできる時間帯を曜日ごとに制限する機能です。

多くの企業では、この機能は単なる「あれば便利なもの」ではなく、セキュリティアーキテクチャの根幹をなす要素となります。例えば、以下のようなシナリオが考えられます。

コンプライアンス要件の遵守

金融サービスや医療業界など、厳格な規制下にある業界では、データへのアクセスを業務時間内に限定することが法的に求められる場合があります。Login Hours を使用することで、これらのコンプライアンス要件を満たし、監査証跡を明確にすることができます。

内部脅威リスクの軽減

セキュリティの脅威は外部からだけとは限りません。従業員の認証情報が漏洩した場合、攻撃者は深夜など監視が手薄になる時間帯を狙って不正アクセスを試みる可能性があります。Login Hours を設定し、業務時間外のアクセスをブロックすることで、このようなリスクの攻撃対象領域（Attack Surface）を大幅に削減できます。

オペレーションの標準化

コンタクトセンターのエージェントやシフト制で働く従業員など、特定の時間帯にのみ業務を行うユーザーグループに対して Login Hours を適用することで、オペレーションの規律を維持し、時間外労働の管理にも繋がります。これにより、企業のポリシーをシステムレベルで強制することが可能になります。

アーキテクトの視点から見ると、Login Hours は Identity and Access Management (IAM) 戦略の重要な一部であり、ゼロトラストセキュリティモデルの考え方にも合致します。「常に検証し、決して信用しない」という原則に基づき、時間というコンテキストを利用してアクセスの妥当性を判断するのです。

アーキテクチャ上の考慮事項と原理

Login Hours の実装は表面的には簡単に見えますが、その背後にあるアーキテクチャとシステム全体への影響を理解することが不可欠です。

設定の継承と優先順位

Login Hours は、Profile (プロファイル) または Permission Set (権限セット) のいずれかで設定できます。ここでのアーキテクチャ上の重要なポイントは、ユーザーに適用されるルールの決定方法です。

  • ユーザーに割り当てられた Profile に Login Hours が設定されている場合、その時間が適用されます。
  • ユーザーに複数の Permission Set が割り当てられており、それぞれに異なる Login Hours が設定されている場合、ユーザーはすべての許可された時間帯の「和集合」でログインできます。例えば、ある権限セットで月曜の9時～12時、別の権限セットで月曜の13時～17時が許可されていれば、ユーザーは月曜の9時～12時と13時～17時の両方の時間帯にアクセスできます。
  • Profile と Permission Set の両方に設定がある場合も同様に、すべての許可時間帯の和集合が適用されます。

この仕様を理解することは、スケーラブルな権限モデルを設計する上で極めて重要です。Profile は基本的なアクセス権の土台とし、特定の業務要件に応じた時間制限は Permission Set で付与するのがベストプラクティスです。

ユーザータイプごとの影響

Login Hours の影響は、ユーザーの利用形態によって異なります。

  1. UI ユーザー: 最も一般的なケースです。許可された時間外にログインしようとすると、エラーメッセージが表示されてアクセスが拒否されます。すでにログイン中のユーザーのセッションは、許可時間が終了しても即座には切断されません。ユーザーは現在のページを閲覧し続けることができますが、レコードの保存やページの移動など、サーバーへのリクエストを伴う新しい操作を行おうとすると、強制的にログアウトされます。
  2. API ユーザー (インテグレーションユーザー): これはアーキテクトが最も注意すべき点です。Login Hours は、UI だけでなく SOAP, REST, Bulk API を含むすべての API アクセスに適用されます。もし、データ連携や外部システムとの同期に使用しているインテグレーションユーザーに意図せず Login Hours を設定してしまうと、許可時間外に実行された API コールはすべて失敗し、深刻なシステム障害を引き起こす可能性があります。
  3. 非同期処理 (Asynchronous Apex): Scheduled Apex や Batch Apex などの非同期ジョブは、それをスケジュールしたユーザーのコンテキストで実行されます。重要なのは、ジョブの実行自体はスケジューリングユーザーの Login Hours の影響を受けないということです。つまり、ユーザーの許可時間外であっても、スケジュールされたジョブは実行されます。ただし、そのジョブ内のコードが、Login Hours が設定された別のユーザーとして API コールアウトを行う場合は、そのコールアウトが失敗する可能性があるため、設計には注意が必要です。

実装例とコード

Login Hours の設定は主に宣言的なUIで行いますが、アーキテクトとしては、設定状況をプログラムで監査・監視できることが重要です。Salesforce は LoginHours という SObject を提供しており、SOQL を使用してプロファイルや権限セットごとの設定を照会できます。

SOQL を用いた Login Hours 設定の監査

以下の SOQL クエリは、特定のプロファイルに設定されている Login Hours の詳細を取得する例です。監査や構成管理の自動化に役立ちます。

// まず、監査対象のプロファイルのIDを取得します。
Profile p = [SELECT Id FROM Profile WHERE Name = 'System Administrator' LIMIT 1];

// 次に、そのプロファイルID (ParentId) を使って LoginHours オブジェクトを照会します。
List<LoginHours> loginHoursForProfile = [
    SELECT
        Id,
        DayOfWeek,
        StartTime,
        EndTime
    FROM LoginHours
    WHERE ParentId = :p.Id
];

// 結果をループして表示します。
// StartTime と EndTime は GMT (グリニッジ標準時) の深夜0時からの分数で格納されています。
for (LoginHours lh : loginHoursForProfile) {
    System.debug('曜日: ' + lh.DayOfWeek); // Monday, Tuesday など
    System.debug('開始時間 (分): ' + lh.StartTime); // 例: 540 (午前9時)
    System.debug('終了時間 (分): ' + lh.EndTime); // 例: 1020 (午後5時)
}

コードの解説

  • ParentId: この項目には、Login Hours が関連付けられている Profile または Permission Set の ID が格納されます。
  • DayOfWeek: 曜日を 'Sunday', 'Monday', 'Tuesday' などの文字列で示します。
  • StartTime / EndTime: 1日の始まり (GMT 00:00:00) からの経過分数を整数で表します。例えば、午前9時 (GMT) は 9 * 60 = 540 となります。この値は常に GMT であるため、組織のタイムゾーンに合わせて計算・変換する必要があります。

このクエリを定期的に実行し、意図しない変更がないか、セキュリティポリシーに準拠しているかを確認する自動化プロセスを構築することは、ガバナンスの観点から非常に有益です。

注意事項とシステムへの影響

Login Hours を導入する際には、いくつかの重要な注意点と、それがシステム全体に与える影響を考慮する必要があります。

タイムゾーンの罠

Login Hours は、常に組織のデフォルトタイムゾーンで解釈されます。これはグローバルに展開している企業にとって最大の注意点です。例えば、組織のタイムゾーンが「日本標準時 (JST)」で、ログイン時間を月曜～金曜の9時～17時に設定したとします。この場合、ニューヨーク（米国東部時間）にいるユーザーは、現地時間の日曜夜～金曜早朝にしかログインできなくなり、業務に大きな支障をきたします。この問題を回避するためには、地域ごとに異なる Login Hours を設定した Permission Set を作成し、ユーザーの所在地に応じて割り当てるなどのアーキテクチャ設計が必要です。

インテグレーションの失敗リスク

前述の通り、API 連携は Login Hours の影響を直接受けます。夜間のバッチ処理やリアルタイム連携が突然失敗し始めた場合、まずインテグレーションユーザーの Login Hours 設定を疑うべきです。これを防ぐための鉄則は、インテグレーション専用のユーザーを作成し、そのユーザーには Login Hours 制限を適用しないことです。可能であれば、「Salesforce Integration」ライセンスと「API Only User」権限を組み合わせ、UIからのログインを完全に無効化することが推奨されます。

権限と管理

Login Hours を設定・変更するには、「アプリケーションのカスタマイズ」および「プロファイルと権限セットの管理」権限が必要です。これらの強力な権限の管理は、変更管理プロセスに則って慎重に行うべきです。誰が、いつ、なぜ Login Hours を変更したのかを追跡できるよう、設定変更の監査証跡を定期的にレビューすることが重要です。

まとめとベストプラクティス

Login Hours は、Salesforce プラットフォームのセキュリティを強化するための基本的かつ効果的なツールです。アーキテクトとして、この機能を最大限に活用し、リスクを最小限に抑えるためのベストプラクティスを以下にまとめます。

  1. 最小権限の原則 (Principle of Least Privilege) の適用

    Login Hours を、ユーザーが必要な時にのみシステムにアクセスできるようにするための手段として活用します。デフォルトですべてのユーザーに24時間アクセスを許可するのではなく、役割や職務に基づいてアクセス時間を制限することを検討してください。

  2. プロファイルではなく権限セット (Permission Sets) を利用する

    Login Hours の設定は、プロファイルを複製するよりも、Permission Set で管理する方がはるかに柔軟でスケーラブルです。役割や地域、プロジェクトなど、様々な軸で時間ベースのアクセス権限グループを作成し、必要に応じてユーザーに割り当てることができます。これにより、「プロファイル地獄」を避け、権限管理を簡素化できます。

  3. インテグレーションユーザーの完全な分離

    システム間連携には、必ず専用のインテグレーションユーザーを使用してください。このユーザーには、Login Hours 制限をかけず、IP 制限 (IP Ranges) を用いてアクセス元を厳格に制御する方が、セキュリティと安定性の両面で優れています。

  4. ガバナンスと監査の徹底

    SOQL や Salesforce Optimizer などのツールを活用し、Login Hours の設定を定期的に監査します。企業のセキュリティポリシーから逸脱した設定がないか、休眠している設定がないかを確認し、設定の健全性を維持します。

  5. 明確なコミュニケーションと変更管理

    Login Hours を新たに導入または変更する際は、影響を受けるユーザーに対して事前のコミュニケーションを徹底してください。なぜこの変更が必要なのか、具体的にいつからどの時間帯に影響があるのかを明確に伝えることで、ユーザーの混乱を防ぎ、サポートへの問い合わせを減らすことができます。

結論として、Login Hours は単なる設定項目ではなく、組織のセキュリティポリシーを具現化し、コンプライアンスを確保するための戦略的なアーキテクチャコンポーネントです。その影響範囲を深く理解し、ベストプラクティスに沿って設計・実装することが、堅牢で信頼性の高い Salesforce 基盤を構築する鍵となります。

コメント

コメントを投稿