Active Directory GDPR分類
GDPRは、データを非個人、個人、および機密個人に分類します。デリケートな個人は、遺伝的および生体認証、人種的および民族的、宗教的および哲学的などにさらに分類されます。
新しいActive Directoryを実装する予定です。GDPRを考慮して、利害関係者にさまざまなオプションを提示したいと思います。
マイクロソフトを読む ホワイトペーパー GDPR分類への属性のマッピング、または3つのアプローチのいずれかを実装する方法の最終結果がわかりません。
私はこれらの線に沿って何かを見たいと思っています：
- 非個人としてクラス化するには：1. userPrincipalNameおよびsAMAccountNameで従業員IDを使用します。 2. homePhone/otherPhoneなどでのみ企業の携帯電話を使用します。 3. streetAddress、targetAddressなどでオフィスの住所を使用します。
- これらを機密として分類しないでください。1.生体認証（Windows Helloなどのデバイスに保存されている場合を除く）。 2.宗教コミュニティの配布リスト（例：複数の信仰がある場合でも祈祷室）
もちろん、ケースバイケースで考慮する必要がある拡張属性があります。
誰かがこのプロセスを経て、自分の仕事から共有できますか？
Geir E.がコメントで述べたとおり、データの最小化を念頭に置いてください。何かのために明示的に必要とされない限り、個人データを使用しないでください。 AD部分全体が完全に非個人的である可能性があり、そうしない理由はありません。
ユーザー名については、従業員IDや部門/チーム/ジョブスコープの派生など、個人の実際の名前を意味しない多くの選択肢を使用できます。
実際に従業員IDがますます使用されるようになると、ほとんどの場合、実際に使用すると従業員管理全体が単純化されます。
従業員IDは、勤務時間カウントシステム、HRシステム、ERPシステムなどで広く使用されているのと同じように、ADで使用できます。
現在個人的なものを使用している場合でも、ADを非個人的なものとして確実に分類できます。 ADアカウントの名前を変更しても、影響は最小限であり、ユーザーが新しいIDでログインする必要がある場合を除いて、機能全体に影響はありません。
当社の場合、このプロセスを経ているかどうかのリクエストをいただいたため、AD、ドキュメント暗号化システムログイン、セキュリティシステムログイン、ERPには従業員IDを使用しています。残っている名前ベースの唯一のものは、ADとはまったく関係のない電子メールです。