Tôi lưu trữ dữ liệu nhạy cảm ở đâu trong Active Directory?


11

Về cơ bản, tôi đang lưu trữ khóa riêng (Hash) trong bất kỳ thuộc tính OctetString nào trong Active Directory.

Câu hỏi của tôi là, thuộc tính nào được bảo mật theo mặc định và có ý nghĩa để giữ dữ liệu riêng tư ở đó? Giá trị này phải được coi là tương tự như mật khẩu, trong đó ngay cả quản trị viên cũng không nên truy cập (nếu có thể), giống như Mật khẩu AD hiện tại.

Dưới đây là phần bắt đầu của danh sách các thuộc tính được bật theo mặc định trên miền Windows 2008R2 + Exchange 2010.

văn bản thay thế

Cập nhật:

Có ai biết thuộc tính Chuỗi Octet không hiển thị quyền "đọc" cho tất cả người dùng trong miền theo mặc định không? Tôi không muốn lưu trữ công khai hàm băm của mình và cho phép ai đó xây dựng bảng cầu vồng dựa trên giá trị băm.

Câu trả lời:


11

Vấn đề mà hầu hết mọi người gặp phải khi lưu trữ dữ liệu trong AD là

  • Mở rộng Schema (thường có ý nghĩa chính trị-công ty)

  • Sử dụng một thuộc tính hiện có và chỉnh sửa các quyền (dẫn đến sự phình to AD / ACL làm tăng DIT của bạn và kích thước sao chép tiếp theo)

Có một lựa chọn khác ... sự lựa chọn tốt nhất trong suy nghĩ của tôi là sử dụng tính năng ít được biết đến này của AD để lấy một thuộc tính hiện có và gắn cờ nó là Bảo mật.

Dưới đây là chi tiết về quy trình


Các quyền mặc định trong Active Directory sao cho Người dùng được xác thực có quyền truy cập đọc vào tất cả các thuộc tính. Điều này gây khó khăn cho việc giới thiệu một thuộc tính mới cần được bảo vệ khỏi bị mọi người đọc.

Để giảm thiểu điều này, Windows 2003 SP1 giới thiệu một cách để đánh dấu một thuộc tính là CONFIDENTIAL. Tính năng này đạt được bằng cách sửa đổi giá trị searchFlags trên thuộc tính trong lược đồ. SearchFlags chứa nhiều bit đại diện cho các thuộc tính khác nhau của một thuộc tính. Ví dụ bit 1 có nghĩa là thuộc tính được lập chỉ mục. Bit mới 128 (bit thứ 7) chỉ định thuộc tính là bí mật.

Lưu ý: bạn không thể đặt cờ này trên các thuộc tính lược đồ cơ sở (những thuộc tính xuất phát từ "trên cùng" như tên chung). Bạn có thể xác định xem một đối tượng có phải là đối tượng lược đồ cơ sở hay không bằng cách sử dụng LDP để xem đối tượng và kiểm tra thuộc tính systemFlags của đối tượng. Nếu bit thứ 10 được đặt thì nó là một đối tượng lược đồ cơ sở.

Khi Dịch vụ thư mục thực hiện kiểm tra truy cập đọc, nó sẽ kiểm tra các thuộc tính bí mật. Nếu có, ngoài truy cập READ_PROPERTY, Dịch vụ thư mục cũng sẽ yêu cầu quyền truy cập CONTROL_ACCESS trên thuộc tính hoặc tập thuộc tính của nó.

Theo mặc định, chỉ Quản trị viên mới có quyền truy cập CONTROL_ACCESS cho tất cả các đối tượng. Do đó, chỉ Quản trị viên mới có thể đọc các thuộc tính bí mật. Người dùng được tự do ủy quyền quyền này cho bất kỳ nhóm cụ thể nào họ muốn. Điều này có thể được thực hiện với công cụ DSACLs, tập lệnh hoặc phiên bản R2 ADAM của LDP. Do đó, không thể sử dụng ACL UI Editor để gán các quyền này.

Quá trình đánh dấu một thuộc tính Bảo mật và thêm người dùng cần xem thuộc tính có 3 bước

  1. Xác định thuộc tính nào để đánh dấu Bảo mật hoặc thêm thuộc tính để đánh dấu Bảo mật.

  2. Đánh dấu bí mật

  3. Cấp cho người dùng chính xác quyền Control_Access để họ có thể xem thuộc tính.

Để biết thêm chi tiết và hướng dẫn từng bước, vui lòng tham khảo bài viết sau:

922836 Cách đánh dấu một thuộc tính là bí mật trong Windows Server 2003 Gói dịch vụ 1

http://support.microsoft.com/default.aspx?scid=kb;EN-US;922836


1
Downvoter: Tại sao điều này có được -1?
goodguys_activate

Tôi nghe nói rằng bit bí mật có thể áp dụng một hình phạt hiệu suất đáng kể. Bạn có biết bất kỳ tài liệu nào hỗ trợ hoặc bác bỏ điều đó không?
Nic

@Nic đăng bài đó như một câu hỏi ... lần đầu tiên tôi nghe về nó
goodguys_activate 20/07/13

2

Bạn luôn có thể mở rộng Active Directory với một trường mới cho mục đích này.

Dưới đây là một tài liệu bao gồm các hướng dẫn về việc thêm một thuộc tính mới và giới hạn quyền trên thuộc tính.


Cảm ơn bạn. Mục tiêu của tôi là sử dụng một thuộc tính hiện có nếu có thể vì khách hàng của tôi vượt quá hoang tưởng về việc này ... họ có quá nhiều FUD trong cách tiếp cận đó ... Tôi hy vọng có một thứ gì đó bản địa nếu có thể.
goodguys_activate

Tôi có thể hiểu sự miễn cưỡng của họ, nhưng tôi không tin có bất kỳ thuộc tính ứng cử viên tốt nào không được sử dụng và bảo mật theo yêu cầu.
Zoredache

1

Giá trị này phải được coi là tương tự như mật khẩu, trong đó ngay cả quản trị viên cũng không nên truy cập (nếu có thể), giống như Mật khẩu AD hiện tại.

Điều này không đúng, thậm chí không sai. Mật khẩu không được lưu trữ. Băm được lưu trữ và quản trị viên tên miền có thể truy cập vào đó. Trên thực tế, bạn thậm chí có thể định cấu hình AD để lưu trữ mật khẩu trong mã hóa đảo ngược nếu bạn muốn.

Không có gì mà bạn có thể loại bỏ quản trị viên tên miền, trong AD. Nếu bạn xóa quyền hoặc thậm chí từ chối, quản trị viên tên miền có thể sở hữu và tự thêm lại. Điều này trái ngược với NDS của Novell, nơi quản trị viên của OU có thể khóa các quản trị viên cấp cao hơn.

Điều tốt nhất bạn có thể làm là sử dụng một thuộc tính hiện có hoặc mới và hạn chế quyền truy cập. Bạn có thể giữ quản trị viên khỏi nó và bạn có thể cho phép kiểm tra thuộc tính để mọi thay đổi quyền truy cập hoặc quyền được ghi lại.


Tôi đang lưu trữ một hàm băm một mật khẩu dành riêng cho ứng dụng của mình.
goodguys_activate

Điều này thuộc về một nhận xét, vì nó không trả lời câu hỏi theo bất kỳ cách nào.
MDMarra

Mark - hai câu cuối cùng của tôi là câu trả lời của tôi cho câu hỏi "Tôi lưu trữ dữ liệu nhạy cảm ở đâu trong Active Directory?"
mfinni

@Maker - Điều đó có ý nghĩa và đó là một kịch bản rất giống với liên kết mà @Zoredache đã đăng ở trên. Đó là câu trả lời gốc: sử dụng thuộc tính hiện có hoặc thuộc tính mới và giới hạn quyền truy cập. Đề nghị bổ sung của tôi, nếu khách hàng của bạn tập trung vào bảo mật, cũng sẽ cho phép kiểm tra thuộc tính đó.
mfinni

@Maker - nếu đó thực sự là một hàm băm một chiều, thì dù sao nó cũng đã khá an toàn rồi phải không?
mfinni
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.