厳しすぎるログイン時間制限、後悔の管理者設定

日付:

後から「やらなければよかった」と思った設計、それは営業プロファイルに安易に適用した厳しすぎるログイン時間制限だ。

当時はセキュリティを“強化したつもり”だった

当時の私は、新しくSalesforceを導入する際に、システム全体のセキュリティを高めることが自身のミッションだと考えていた。業務時間外のデータアクセスはリスクであるという漠然とした認識が先行し、「ユーザーが定時外にSalesforceにログインできないようにすれば、不正アクセスや情報漏洩のリスクを減らせる」と、かなり単純な発想で設計を進めてしまった。

具体的には、営業担当者が使用する主要なプロファイルに対し、ログイン時間を「月曜〜金曜の9時から18時まで」と厳しく設定した。これは一般的な日本のオフィスアワーに合わせたものだ。

当時の私は「これで従業員の業務とプライベートの境界線も明確になり、コンプライアンス的にも良いだろう」と、自信満々だった。上層部からも「セキュリティ意識が高い」と評価されるだろうとすら思っていた。

具体的に何が起こったか：運用悪夢の始まり

1. 緊急対応の阻害

最初に問題になったのは、営業からの緊急連絡だった。顧客から緊急の問い合わせがあり、定時後に自宅からモバイルアプリでSalesforceにログインして顧客情報を確認しようとしたが、「ログイン時間が制限されています」というエラーでログインできない。クレームが私に直接入るようになった。「なぜ、こんな重要な情報にアクセスできないのか！」と。

2. 海外拠点との連携問題

次に、時差のある海外拠点との連携でトラブルが発生した。日本の営業担当者が海外の顧客や担当者とやり取りをする際、日本の定時外（早朝や夜間）にログインが必要になるケースが頻繁にあった。当然、これもログイン制限でブロックされ、業務が滞った。結局、そのたびに「一時的に制限を解除してほしい」という申請が入り、その対応に追われることになった。

3. 連携ユーザーへの影響（最大の失敗）

そして、最も大きな判断ミスだったと今でも思っているのが、システム連携用のユーザープロファイルにも、この営業プロファイルのログイン時間制限が引き継がれて適用されていたことだ。

Salesforceと外部のBIツールや基幹システムを連携させる際、専用の連携ユーザー（インテグレーションユーザー）を設定していた。これらのユーザーは、夜間バッチ処理や定期的なデータ同期のために、深夜や早朝にもSalesforceにアクセスする必要がある。しかし、厳しく設定されたログイン時間制限のために、連携処理がスケジュール通りに実行されず、データが同期されない事態が頻発した。

具体的には、UserオブジェクトのProfileIdを参照し、連携ユーザーも一般的な営業プロファイルと同じプロファイルを割り当ててしまっていたのだ。当時の私は、連携ユーザー用のプロファイルを用意するという発想が希薄で、安易に既存のプロファイルを使い回してしまった。これはもう、完全に設計ミスとしか言いようがない。

// 当時の連携ユーザーの設定（イメージ）
// 実際にはUIでプロファイルを割り当てていた
User integrationUser = new User(
    ProfileId = [SELECT Id FROM Profile WHERE Name = 'Standard User - Sales' LIMIT 1].Id, // ここが問題だった
    UserName = 'integration@example.com',
    ...
);
insert integrationUser;

この結果、夜間のバッチ処理がエラーになり、朝にはデータが古いままでレポートが出力されるなど、ビジネスに直結する深刻な影響が出た。

今なら別の選択をする

あの時の私は、セキュリティ「強化」という漠然とした目標に囚われすぎて、実業務の多様性や、システム連携の要件まで考慮が及んでいなかった。結果として、利便性を著しく損ね、かえって運用を複雑にしてしまった。

今なら、ログイン時間制限は基本的にデフォルト（無制限）を推奨する。そして、本当に業務時間外のログインを厳格に制限する必要がある特定のプロファイル（例: 完全なテストユーザーや、特定の期間限定プロジェクトメンバーなど、ごく限定的で明確な業務定義がある場合）にのみ適用を検討する。

特に連携ユーザーのプロファイルには、絶対にログイン時間制限を設定してはならない。彼らは人間ではなくシステムであり、24時間365日の稼働を前提としているからだ。別途専用のプロファイルを作成し、ログイン時間制限は無効化するべきだった。

セキュリティについては、ログイン時間制限のような強い強制力を持つ機能ではなく、IPアドレス制限、多要素認証（MFA）、セッション設定、あるいはアクセスログによる監視など、より柔軟で、かつ業務を阻害しにくい方法を優先すべきだと考えている。

あの時、もう少し想像力を働かせていれば、こんな回り道はしなかっただろう。これは当時の自分向けのメモだ。

コメント

コメントを投稿