メンバーは役割に基づいて権限を受け取り、アカウント、環境、マシンは所属に基づいて人々に割り当てられます。バインディングを変更し、戦略を調整し、実行量を増やします このような操作は操作ログに記録され、人や時間ごとに取得することができます。マネージャーアカウントは 2 段階認証を強制できます。
バックエンド アカウントはグループ全体で共有されており、誰が変更したかは誰も知りません。
各人はアカウントを持ち、行動はそれぞれの名前で記録されます。操作ログは人別、時間別に取得できるため、思い出しや相互尋問が不要になります。
オペレーターはすべてのアカウントを表示できますが、実際に管理しているのは 3 つの市場のみです
アカウント、環境、マシンは、その所有関係に従って割り当てられます。非表示のリソースは、操作中にブロックされるだけでなく、リストにも表示されません。
本人はいなくなってしまったが、アカウントのパスワードとAPI Keyは今も外に散乱している。
メンバーは削除せずに非アクティブ化でき、履歴は保持されます。 API キーは個別に管理され、目的に応じて個別に作成および無効化できます。
何か問題が発生した場合、推測に頼るしかありません。作成できるレコードはありません。
バインディングの変更、ポリシーの調整、スクリプトのスケーリング、権限の変更などのアクションのログがあります。レビュー中にチェックできる特定の項目があり、全員の意見を反映するわけではありません。
アクセスはログイン セキュリティに依存し、実行できる内容は権限に依存し、実行された内容はログに依存します。という 3 つのことが個別に行われます。 1 つがなければ、他の 2 つは役に立ちません。
メンバーは個別に作成され、有効または無効にすることができます。履歴とログの保持を無効にしても、実行されたアクションの追跡可能性には影響しません。
よく使用される権限をロールに結合し、ロールに応じて新しいユーザーを有効にします。役割は、事業分野または責任ごとに個別に設定できます。
権限は機能項目に基づいて付与され、特定の種類の操作を実行できるかどうかなど詳細に指定できます。同じ人が異なるリソースに対して異なる権限を持つことができます。
メンバーとリソースは組織とグループに分割されます。アカウント、環境、マシンの所有権は明確であり、デフォルトではグループ間のリソースは相互に表示されません。
リソースは、それが属するユーザーを示します。マネージャーは、トラブルシューティングで支援が必要なときにユーザーの視点に切り替えることができ、切り替えアクション自体もログに記録されます。
メンバーの変更、権限の変更、アカウントと環境のバインディングの変更、スクリプトの実行などのアクションは 1 つずつ保存され、人や時間ごとに取得できます。
メンバーは 2FA を有効にすることができ、管理アカウントではこれを必須にすることをお勧めします。ログイン プロセスにはグラフィック確認コードがあり、これによりバッチ パスワード試行の成功率が低下します。
キーは目的に応じて個別に作成、表示、無効化されます。プログラム側の通話は人間の操作とは別に記録されるため、問題が発生した場合に原因を特定できます。
役割分担と高リスク権限の付与については、お客様が確認する必要があります。アクセス許可が付与されると、ログは何が起こったのかを伝えることしかできませんが、その発生を防ぐことはできません。
まず、各ポジションが何をできるべきかを考えます。つまり、アカウントのバインドを変更できるのは誰なのか、大量のスクリプトを実行できるのは誰なのか、データの読み取りのみができるのは誰なのかなどです。この役割を決めます。
メンバーは 1 人ずつ作成され、役割に応じて承認されます。グループに参加すると、グループに表示されるアカウント、環境、マシン範囲が自動的に継承されます。
2FA は、メンバーが初めてログインしたときにバインドされます。管理役割を強制的に有効にすることをお勧めします。ログイン プロセスにはグラフィック確認コードがあります。
バインディングの変更、ポリシーの調整、権限の変更、スクリプトの実行、ユーザーの切り替えなどのアクションは、メンバーによる追加の操作を必要とせずに、操作ログに書き込まれます。
人事異動後は速やかにアカウントを停止し、対応するAPIキーを無効化してください。ログ内のリスクの高いアクションを定期的に確認し、問題が発生するまで待って初めてログを開かないでください。
権限の境界を設定できるのはあなただけです。システムは、社内の誰がどの顧客を参照すべきか、またはどの役職が外部関係者にメッセージを送信する資格があるのかを知りません。これは組織的な決定であり、技術的な判断ではありません。デフォルト設定が最も簡単ですが、何か問題が発生した場合、ログはプロセスを復元できますが、損失は復元できません。
権限制がセキュリティのすべてと考えないよう、システムが管理するものと自分で管理したいものを明確に書き出してください。
環境はグループごとに分類され、作成、バインディング変更、エージェント変更などの操作が操作ログに記録されます。
マイマシンと管理対象マシンを所属ユーザーごとに分け、機器の割り当てやリサイクルを記録します。
スクリプトの作成と大規模な実行を別々に認可し、目的に応じてAPI Keyを別々に管理・無効化します。
顧客リストと会話履歴はグループで表示され、承認されたメンバーのみが転送時に引き継ぐことができます。
できません。ログは事後追跡の手段であり、事前に傍受する手段ではありません。誰がいつ何を変更したかはわかりますが、変更の瞬間に停止することはできません。実際に傍受の役割を果たすのはアクセス許可です。ユーザーがアクセスできるリソースと、その責任の範囲内で実行できるアクションを制限し、顧客データのエクスポート、大量のスクリプトの実行、アクセス許可の変更などのリスクの高いアクションのみを少数のユーザーにのみ付与します。もう 1 つの部分は、退職日にアカウントを非アクティブ化し、対応する API キーを無効にし、権限を定期的に確認し、リスクの高いアクションについて抜き取りチェックを実施するなど、システムに依存しています。ログ、権限、システムが整備されて初めて防御線を築くことができます。ログを確認するだけでは、モニタリングはインストールするがロックはインストールしないのと同じです。
権限は機能項目に基づいて付与され、モジュールに入ることができるかどうかだけでなく、特定の種類の操作を実行できるかどうかまで詳細に付与されます。同時に、リソースには所有権関係があり、同じ人が異なるアカウント グループに対して異なる権限を持つことができます。権限項目の特定のリストは、バックグラウンドで項目ごとに表示できます。
履歴と操作ログが保持されるように、削除ではなく非アクティブ化します。同時に、彼の名前の API キーを無効にし、彼が担当するアカウントと環境を新しいユーザーに変更する必要があります。共有資格情報を使用しているプラットフォーム アカウントのパスワードを変更することをお勧めします。
権限の構成に応じて異なります。マネージャーはグループ間の表示権限を取得でき、ユーザーの視点を利用してトラブルシューティングを支援することもできますが、ユーザーを切り替えるアクションはログに記録されます。特定の顧客データを厳密に分離したい場合は、グループ化と権限を制限し、グループ間の表示権限を与えないようにすることができます。
メンバーは自分でこれをオンにすることができますが、管理ロールには必須にすることをお勧めします。特定の必須ポリシー構成方法は、バックグラウンド設定にあります。少なくとも、権限を変更してスクリプトを大量に実行できるロールに対しては、これを開くことをお勧めします。
バックグラウンドで人別・時間別の操作ログを取得できます。エクスポート方法と保存期間—、コンプライアンス監査要件がある場合は、計画コミュニケーションの段階で説明し、必要に応じて保持戦略を確認してください。
コンサルタントは、チームの立場と分業に基づいて、役割分担の提案とリスクの高い行動の管理リストを提供します。