権限をどのように文書化/追跡しますか
私はWindowsの管理者なので、Windowsと統合されているユーザーが最も役に立ちます。この時点での私の主な課題は、ファイル共有だけですが、SharePointの使用が増えるにつれて、これを難しくするだけです。
すべてのディレクトリをセットアップしました。必要な最小限のアクセスのポリシーでセットアップされた多くのセキュリティグループが許可されています。私の問題は、人事およびコンプライアンス上の理由ですべてを追跡することです。
ユーザーAにはリソース1へのアクセス許可が必要です。ユーザーAはリソース1のマネージャーから承認を得る必要があり、マネージャーのマネージャーもこのアクセスを承認する必要があります。すべてが完了したら、変更を加えることができます。この時点では紙で追跡しているだけですが、ユーザーAが再割り当てされ、他のシナリオの中でリソース1にアクセスできなくなった場合、負担が大きくなり、コンプライアンスから外れる可能性があります。
探しているものがすでに存在しているはずですが、どこを見ればよいのかわからず、コミュニティに連絡しています。
編集：
回答ありがとうございます。彼らは技術的な側面に触れていると思います。うまくいけば、私の質問は主題外ではありません。私は自分の目標を明確にすべきだった。 X日にユーザーAに権限が追加/削除され、マネージャーYによって承認されたことを監査人に示すためにどのシステムを使用しますか？現在、基本的な発券システムを導入していますが、必要なものがわかりやすい形式で提供されているとは思いません。
私の心では、ユーザーAに関するレポートがあり、ユーザーのアクセス許可に加えられたすべての変更を表示するようなものを描いています。理想的には、Active Directoryにリンクするものが理想的ですが、現時点では、より基本的なものを見つけたいと思っています。このためのアプリケーションがあることを願っています。これは大企業の要件である必要があると思います。そのようなソフトウェアは存在します。
ありがとう！
次の3つを提供する発券システムが必要です。
- 特定のユーザーのアクセス許可が変更（追加または削除）されたときのタイムスタンプ
- なぜ変更されたのか
- これらの変更を検索する機能
ほとんどすべての発券システムでは、チケットの作成日、変更日などの形式で＃1がすでに提供されています。＃2はチケットに記録する必要があります。通常、これはチケットに貼り付けられたリソースマネージャからの承認電子メールであり、アクセス権（またはアクセス権を削除する必要がある）とその種類を示します。 ＃3が最も重要であり、発券システムに依存しますが、検索が容易ではないシステムを使用している場合、あなたの仕事はあなたのために切り取られます。すべての許可チケットが発券システムの連絡先情報に関連付けられるようにユーザーで検索できる場合は問題ありません。それ以外の場合は、基本的に変更をブラックホールに文書化します。
変更を追跡するためにこれを行うことができるチケット発行システムの外（基本的なチケット発行システムがあるため、検索/レポート機能を向上させるために、より良いものを取得する必要があるかもしれません）、使用するアプリケーション、ユーティリティ、またはスクリプト権限のスナップショットのみを提供します。あなたはまだ「なぜ？」に行き詰まっています。リソースマネージャーから元の電子メールまたはその他の承認テキストをキャプチャする必要があるため、アプリケーションとは別に適切に文書化できるのは、誰が何にアクセスできるかです。それができたら、それをアプリケーションの結果と関連付けるためにどこに配置しますか？
アプリまたはスクリプトを実行してファイル構造内の現在の権限を判断しても、ユーザーの権限変更の素敵な監査証跡は提供されません。基本的に、ある時点での現在の権限の大きなスナップショットで立ち往生しています。もう一度実行すると、ファイルのアクセス許可の別の大きなスナップショットが作成されます。最初のアクセス許可のキャプチャを保持し、それを最近のキャプチャと比較して、アクセス許可が変更されたとしても、それを変更の理由にどのように結び付けますか？ここでも、上記の＃1、2、および3がすべて1か所に文書化されるため、これによりチケットシステムに戻ります。
あなたが提起したもう1つの問題は、権限のクリープです（ユーザーが別の権限に再割り当てされ、リソースXへのアクセスが不要になったが、リソースXへのアクセスが必要なくなったという事実がITによって実行されなかったため、それを保持している場合）移行中の部署）。これを制御する唯一の方法は、HRまたは従業員の再割り当てを処理する人に、従業員が再割り当てされたときにITに通知する必要があることを伝え、適切に権限を割り当て、取り消すことです。それでおしまい。ユーザーにリソースXへのアクセス権があることを通知する魔法のアプリケーションはありませんが、ユーザーの仕事がYになったため、もう必要ありません。これが発生した場合、何らかの形で人に通知する必要があります。
これを行うための実際の商用アプリケーションがいくつかあります。この領域は、「データガバナンス」と呼ばれることもあります。
いくつかの例：
Varonis Data Governance Suite
http://www.varonis.com/products/data-governance-suite/index.html
Quest One Identity Manager – Data Governance Edition
http://www.quest.com/identity-manager-data-governance
私はこれらを使用しませんが、トピックを調査し、いくつかのデモを見て、必要とされる可能性のあるものの範囲が市場を説明します。これらのアプリケーションは非常に複雑で、安価ではありません。それらのいくつかは、アクセス制御リストを追跡するためにストレージプラットフォームにフックする非常に高度な方法を備えています。予算に収まっていない場合でも、デモは、このようなアプリケーションの機能を機能的な観点から理解するのに役立ちます。
これを確認しているときに気付いたのは、通常、ファイルレベルで監査を行わないことです。そうした場合、数億または数十億のドキュメントにスケールアップする方法はありません。そのため、通常はディレクトリレベルでのみ権限を追跡します。
すでに発券システムを導入している場合は、これらのタイプのリクエストのためにアプリケーションに新しいグループやタグなどを作成し、ユーザーに権限の変更のチケットを送信してもらうことをお勧めします。チケットシステムでチケットを他のユーザーに転送したり、チケットに追加したりできる場合は、必要なマネージャーを追加して、確認を依頼します。これは、あなたの仕事をカバーするために記録を保持することを可能にします。
上記のように、すべての共有に対してセキュリティグループを作成します。私の環境では、FIN_Yearly、GEN_Public、MGM_Reportsという名前の共有があります（各部門には独自の頭字語があります）。セキュリティグループには、SG_FIN_YearlyAdmin、SG_FIN_YearlyUser、SG_GEN_PublicAdminなどの名前が付けられます。ユーザーは読み取り専用で、Adminは読み取り/書き込み可能です。
ここから、たとえばSG_FinancialsManagerを作成できます。実行するジョブに基づいてアクセスを簡略化するために、他のセキュリティグループを含むセキュリティグループ。私たちは個人的にこれをしません。共有のSGをチェックして、権限を持つ一連のSGを確認するのではなく、代わりにユーザーのリストを用意しています。個人的な好みは、本当に、そしてあなたのサイトのサイズに依存します。私たちは通常、新しいユーザーを特定の位置に管理するためにユーザーテンプレートを使用します。
チケットシステムで以前のチケットを検索できる場合は、ほぼ完了です。誰かがユーザーの権限を削除するように要求した場合、それを追跡できます。ユーザーがアクセスできない理由を質問した場合は、チケットを提供できます。誰が何にアクセスできるかをマネージャーから尋ねられた場合、要求されたセキュリティグループをprintscreenします。
私はそれらをドキュメント化/追跡することは知りませんが、私は割り当てグループに割り当てます。
ユーザーAはリソース＃1にアクセスする必要があります。彼らは許可を得て、私はそれらをアクセスグループに追加します。
彼らは彼らが再割り当てされる/解雇される/何であれ彼らが彼らのビジネスについて続けます、その時点で私は彼らをアクセスグループから削除します。
私のアカウント変更監査ログは、それらがアクセスを取得した/失ったことを教えてくれるので、その記録があります。また、リソースアクセスグループは通常、部門グループ（HR、IT、セールス、財務など）なので、再割り当ての管理は通常、グループの変更を意味しますとにかくメンバーシップ。
これは、小さな環境で最もよく機能する傾向があります-大規模な環境やACLが本当に複雑になる環境 Zoredacheは、ACLを微調整するシステムにある程度の文書化を行わせることについて優れた点を示しています
アクセスの追加/削除、ユーザーの再割り当てなどのリクエストを開始するには、電子ペーパー（発券システム）をお勧めします-これにより、ユーザーが亀裂をすり抜けることはありませんが、電子システムを確実に使用するには、企業全体の賛同が必要です。 。
紙よりも優れている点は、検索できるものが手に入り、誰もが自分のデスクからプロセスの一部を実行できることです（オフィス間のメールエンベロープが移動しないため、マネージャはより迅速に承認でき、ITが許可/チケットが誰かの箱などに現れたらすぐにアクセスを取り消す）
権限設定を行うために私が見つけた最良の方法は、役割ベースです。
GG_HR GG_Financeなど。通常、ポジションまたはビジネスユニットにマッピングされます。
そこから、リソース、つまりプリンタ、またはファイナンスディレクトリに対する権限を持つローカルグループを作成します。 LG_RoomXPrinter LG_Finance_Read LG_Finance_FullControl
これらのローカルグループLG-> GGのグローバルグループを作成し、役割ベースのグローバルグループで、権限ベースのグローバルグループを追加します。
GG_Finance <-LG_Finance_FullControl、LG_RoomXPrinter
ユーザーが役割に入るときに簡単にできます。アカウントを1つのグループに追加するだけで、その役割からの権限フローが追跡され、追跡がはるかに簡単になります。 （また、ある種のID管理システムを使用している場合にも最適です）。誰がどの権限を持っているかを追跡するよりもはるかに簡単です。彼らがHRグループに属している場合、X権限を持っていることがわかります。
ジョブ管理システムを介して要求されたときにグループの動きを追跡するか、スクリプトを実行して、どのロールベースのグループに誰がいるかを吐き出すことができます。
2つの優れたユーティリティ：
- AccessEnum： http://technet.Microsoft.com/en-us/sysinternals/bb897332
- AccessChk： http://technet.Microsoft.com/en-us/sysinternals/bb664922
AccessEnumを使用すると、その結果を保存して、将来それらを比較することもできます。これは、変更を探すのに役立ちます。
ファイル/フォルダーのアクセス許可の変更の監査を有効にして、ファイルサーバーのセキュリティログを（手動で、またはSplunkなどのイベントログ管理ツールやSIEMを使用して）収集し、それをドキュメントに使用することを検討する必要があります。ファイルDACLに対するすべての変更を分析します。さらに、上記のようにAccessEnumとAccessChkでこれを補完します。
また、適切なセキュリティ権限を設定し、グループのみを介してそれらを割り当てることから解放されません。