物理的保護
まず、物理的な情報保護が必要です。データサーバーが盗まれないようにするためです。 このため、サーバーは、ビデオ監視を備え、これらの施設へのアクセスが制限されている24時間警備されたデータセンターに配置されています。 従業員の限られたサークルのみがそこに許可されており、顧客代表も、開発会社の他の従業員もそこに着くことはできません。
物理的保護の2番目のレベルは、これらのサーバーに含まれるデータの安全性を確保することです。 この問題は、情報バックアップのポリシーを適用することで解決されます。このポリシーでは、データベースとCRMファイルの毎日の自動コピー、および週に2回、個別の外部サーバーとローカルのリムーバブルメディアへのコピーが提供されます。
データ層保護
データ送信には保護が必要です。これは、送信時に情報が傍受される可能性があるためです。 Webアクセスを備えたクラウドシステムの場合、SSL証明書を使用してhttpsプロトコルを使用することが重要です。 その結果、トラフィックの暗号化により、システムデータがスニファーなどによって傍受されるのを防ぐことができます。
システムでの承認
各ユーザーは、自分に割り当てられたユーザー名とパスワードにログインします。 このプログラムは、ユーザーが利用できるソリューションと組織の可用性を自動的に判断し、利用可能な場合は、エントリのベースを選択するように求めます。 そのようなプログラムが1つしかない場合は、追加の質問なしでログインします。
ユーザーパスワードデータは、ハッシュ形式の閉じた形式でデータベースに保存されます。
許可されたユーザーのセッションの盗難を避けるために、システムの各ページの読み込み時にログインとパスワードのハッシュがチェックされます。 認証に失敗した場合、ユーザーは自動的にシステムからログアウトします。
権利とオブジェクトのシステム
CRMの開発で使用されるアルゴリズムの便利なバリアントの1つは、「システム内の各操作は個別のアクセスオブジェクトです」という位置に基づいています。 このアクセスオブジェクトには、個々の従業員の権利を割り当てることができます。 このモデルは、任意のアクセス制御ポリシーに近いため、行がシステムオブジェクトで、列がプログラムユーザーである権利テーブルを作成できます。 列と行の交差点に+または-が配置されます。これは、特定のシステムオブジェクトへの従業員のアクセスの有無を意味します。 したがって、各ユーザーは、このテーブルで独自の個別の列を取得し、ユーザーが使用できる一連のアクションとしてプログラムに実装されます。
この表の理解を容易にするために、システムオブジェクトはテーマグループに分けられます。
そのようなテーブルの例を次に示します。
CRM権利管理インターフェイスは、この表と同様に構築されています。
利用可能な権利の表は、各CRMページを読み込む際のユーザー認証中に自動的に生成されます。 この場合、プログラムは、現在のユーザーがこのアクションまたはそのアクションに対する権利を持っているかどうかを確認できます。 これは、次のような1行のコードで実行されます。
$au->user_rights->CheckAccess(64);
表示されたテーブルに関連してこのメソッドを呼び出すと、オブジェクト64へのアクセスがあるかどうかを確認できます-現在のユーザーのアイテムのリストを表示します。
したがって、プログラムはシステム内の対応するセクションを表示するかどうかを示します。
ロールごとのドキュメントレベルでのCRMのアクセス制御
多くのシステムオブジェクトでは、役割によるアクセス制御が必要です。 ロールは、会社の従業員の資格情報のセットに従って、システム内のデータへのアクセスを反映します。 たとえば、部門の長は、その部門のすべての従業員が提示した商用オファーにアクセスでき、各従業員は自分の商用オファーにのみアクセスできます。
ロールポリシーは、プログラムセクションの設計中に定められ、「ブラックボックス」の原則に従ってプログラムレベルで実装されます。現在の従業員のプロファイルに基づくドキュメントリストクラスは、特別な方法を使用して利用可能なドキュメント番号のリストを返します。セクションに多数のドキュメントが含まれる場合は、正式なルールそれらをフィルタリングします。 たとえば、これらは、ドキュメントを含むデータベーステーブルまたはドキュメントにアクセスできる従業員のリストへのSQLクエリをフェッチするためのパラメータです。
たとえば、部門マネージャーが自分のレコードと部下の従業員のレコードの両方を処理できるように、スケジューラーレコードへのアクセスを設定できます。 プログラムでは、このようなアクセスアルゴリズムは簡単な方法を使用して決定されます。
$viewed_ids=$_plans->GetAvailableUserIds($result['id']);
このメソッドは、指定された従業員にレコードが表示される従業員のリストを返します。 リストは、スケジューラレコードを格納するデータベーステーブルへのSQLクエリのクエリパラメータに置き換えることができます。
この方法の「内部」は、すべての役割ポリシーの実際のソフトウェア実装です。
ユーザーによるドキュメントレベルでのCRMのアクセスの差別化
プログラムの特定のセクションでは、ドキュメントレベルでのアクセス制御が実装されています。 たとえば、ファイルセクションでは、個々のユーザーレベルでフォルダーへのアクセスを制御できます。システム管理者は、フォルダーに対するすべての権限を従業員と共有できます（サブフォルダーの作成、削除、ダウンロード、削除、フォルダーとファイルの移動）。現在、管理者によって彼に割り当てられている権利。
上記の機能は、ファイルレジストリフォルダの「共有」ボタンとして実装され、次のようなウィンドウが表示されます。
たとえば、「Employee 2」の下で働いています。 「自分で足を踏み入れる」可能性は除外されます-自分へのフォルダへのアクセスを閉じるため：対応する行のチェックマークは無効です。 「ファイル記述の編集（自分のファイル）」列は非アクティブです。 このバージョンのシステムでは、従業員2にはそのような権利はありません。 彼にはダニがいます このフォルダに対して、そのような権利はまだ彼に与えられました。
セキュリティレポート
プログラムデータへのアクセスの事実は、システムログに記録されます。 これにより、管理者は誰がどのデータにアクセスしたかを追跡できます。 syslogエントリ自体には、次のフィールドがあります。
- 実施日
- アクション名
- アクションが実行されたIPアドレス
- アクションをコミットしたユーザー
- 影響を受けるユーザー（存在する場合）
- 影響を受けるユーザーグループ（存在する場合）
- 権利テーブルの使用権
- 影響を受ける文書コード
- コメント（更新されたフィールドの値、アクションの説明などを含む）
プログラム内のシステムログは、リストされたフィールドのいずれかでフィルタリングできます。
これは、システムログがどのように見えるかです。 特に、従業員2がテスト従業員から特定の権限を削除したことを示しています。
一般ジャーナルの構造により、プログラムは各ドキュメントのイベントログ（たとえば、アカウントイベントログ）を実装します。 このジャーナルを研究した後、誰がどの情報に、いつ、どのアクションがこの文書に具体的に貢献したかを知ることができます。
さらに、CRMレポートは「ユーザーアクティビティ」で利用できます。 特定の期間における特定の従業員の稼働時間（合計、日別、セッション別）を検索し、この従業員の完全なイベントログを表示できます。
最後に、CRMイベントログを使用して、システム内の従業員のリアルタイムの作業に関するプログラムレポートモジュール（テーブルとグラフの形式）が作成されます。 この機能により、従業員の時間の使用を制御できます。
そのようなグラフィカルなレポートの例を示します。
まとめ
したがって、CRMの情報セキュリティシステムは、いくつかの主要な目標を追求します。一方では、各従業員が作業に必要なデータにアクセスできるという前提に基づいている必要があります（また、偶発的な損傷や削除に対して保証されています）当事者の場合、不正アクセスから会社の商業情報を保護する必要があります。 クラウドCRMでは、これらの問題を一度に解決するためにいくつかのツールが使用されます。これにより、目標を達成できるだけでなく、すべてのメリットについて、デスクトップアプリケーションと同じくらい安全になります。