Tại sao không để lộ khóa chính

Trong giáo dục của tôi, tôi đã nói rằng việc để lộ các khóa chính thực tế (không chỉ các khóa DB, mà tất cả các trình truy cập chính) cho người dùng là một ý tưởng thiếu sót.

Tôi luôn nghĩ đó là một vấn đề bảo mật (vì kẻ tấn công có thể cố đọc những thứ không phải của họ).

Bây giờ tôi phải kiểm tra xem người dùng có được phép truy cập không, vậy có lý do nào khác đằng sau nó không?

Ngoài ra, vì người dùng của tôi phải truy cập dữ liệu dù sao tôi cũng cần có khóa công khai cho thế giới bên ngoài ở đâu đó ở giữa. Bây giờ khóa công khai có cùng vấn đề với khóa chính, phải không?

Đã có yêu cầu của một ví dụ về lý do tại sao làm điều đó, vì vậy đây là một. Hãy nhớ rằng câu hỏi có nghĩa là về chính nguyên tắc không chỉ nếu nó được áp dụng trong ví dụ này. Câu trả lời giải quyết các tình huống khác được chào đón rõ ràng.

Ứng dụng (Web, Di động) xử lý hoạt động, có nhiều UI và ít nhất một API tự động để liên lạc với hệ thống giao tiếp (eG bộ phận kế toán muốn biết khách hàng phải trả bao nhiêu tiền dựa trên những gì đã làm). Ứng dụng có nhiều khách hàng nên việc tách dữ liệu của họ (về mặt logic, dữ liệu được lưu trữ trong cùng một DB) là điều bắt buộc của hệ thống. Mỗi yêu cầu sẽ được kiểm tra tính hợp lệ bất kể điều gì.

Hoạt động có dạng hạt rất mịn nên nó nằm cùng nhau trong một số đối tượng chứa, hãy gọi nó là "Nhiệm vụ".

Ba usecase:

1. Người dùng A muốn gửi Người dùng B đến một số Tác vụ để anh ta gửi cho anh ta một liên kết (HTTP) để thực hiện một số Hoạt động ở đó.
2. Người dùng B phải ra ngoài tòa nhà để anh ta mở Nhiệm vụ trên thiết bị di động của mình.
3. Kế toán muốn tính phí khách hàng cho Nhiệm vụ, nhưng sử dụng hệ thống kế toán của bên thứ ba tự động tải Nhiệm vụ / Hoạt động theo một số mã đề cập đến REST - API của Ứng dụng

Mỗi usecase yêu cầu (hoặc trở nên dễ dàng hơn nếu) tác nhân phải có một số định danh địa chỉ cho Nhiệm vụ và Hoạt động.

Ngoài ra, vì người dùng của tôi phải truy cập dữ liệu dù sao tôi cũng cần có khóa công khai cho thế giới bên ngoài ở đâu đó ở giữa.

Chính xác. Lấy HTTP không trạng thái, người khác sẽ không biết nên yêu cầu tài nguyên nào: nó hiển thị ID câu hỏi của bạn 218306trong URL. Có lẽ bạn đang thực sự tự hỏi liệu một định danh tiếp xúc có thể dự đoán được ?

Những nơi duy nhất tôi nghe thấy câu trả lời tiêu cực cho điều đó, đã sử dụng lý do: "Nhưng họ có thể thay đổi ID trong URL!" . Vì vậy, họ đã sử dụng GUID thay vì thực hiện ủy quyền thích hợp.

Tôi có thể tưởng tượng một tình huống mà bạn không muốn định danh của mình có thể dự đoán được: thu hoạch tài nguyên. Nếu bạn có một trang web mà công khai tổ chức các nguồn lực nhất định những người khác có thể thú vị trong, và bạn lưu trữ chúng thích /images/n.jpghoặc /videos/n.mp4nơi nchỉ là một số incrementing, bất cứ ai nhìn vào giao thông đến và đi từ trang web của bạn có thể thu hoạch tất cả các nguồn lực của bạn.

Vì vậy, để trả lời trực tiếp câu hỏi của bạn: không, không có gì xấu khi trực tiếp "phơi bày" các định danh chỉ có ý nghĩa đối với chương trình của bạn, thông thường nó thậm chí còn được yêu cầu để chương trình của bạn hoạt động.

Bạn không nên phơi bày vì những người nhìn thấy nó sẽ bắt đầu sử dụng nó làm 'số tài khoản' của họ mà KHÔNG phải vậy. Ví dụ, đối với tài khoản ngân hàng của tôi, tôi biết số tài khoản của mình là gì. Tôi đã ghi nhớ nó, tôi sử dụng nó trên điện thoại với dịch vụ khách hàng, tôi sử dụng nó khi điền vào các biểu mẫu cho các ngân hàng khác để thực hiện chuyển khoản, cho các tài liệu pháp lý, cho dịch vụ thanh toán tự động của mình, v.v. nó để thay đổi. Mặt khác, khóa chính (đối với tài khoản của tôi), tôi không biết hoặc chưa từng thấy.
Hệ thống lưu trữ hệ thống thay đổi qua nhiều năm từ hệ thống này sang hệ thống khác, thông qua sáp nhập ngân hàng, nâng cấp và thay thế hệ thống, v.v.
Các khóa chính có thể thay đổi thông qua một số chuyển đổi này, vì vậy nếu nó không bao giờ bị lộ, ghi hoặc ghi nhớ bởi bất kỳ người dùng thông thường nào '
Các khóa không có ý nghĩa kinh doanh thường được gọi là khóa thay thế và thường (nhưng không phải luôn luôn) được sử dụng làm khóa chính.

Tuy nhiên, điều này thậm chí xảy ra trong nội bộ khi mọi người xây dựng các giao diện và chương trình sử dụng sai và lộ các khóa chính và biến chúng thành một phần của các hệ thống đó thay vì chúng chỉ làm một việc - xác định duy nhất một bản ghi cơ sở dữ liệu trong nội bộ. Tôi thực sự đã học được những điều trên thông qua 6 năm hỗ trợ hệ thống kho dữ liệu trong bệnh viện.

Bởi vì Khóa chính là một chi tiết thực hiện.

Nếu bạn di chuyển cơ sở dữ liệu, các khóa chính của bạn có thể thay đổi do thứ tự chèn, xóa các bản ghi cũ ... một vài lý do khác nhau. Nếu bạn di chuyển nền tảng cơ sở dữ liệu, bạn có thể không còn có khóa chính thực sự nữa. Phơi bày PK phía trên lớp truy cập dữ liệu là một sự trừu tượng bị rò rỉ, với tất cả các mối quan tâm khớp nối đòi hỏi.

Đây là một câu trả lời kết hợp của những người khác (aka. Những gì tôi đã học được). Nếu bạn cảm thấy muốn nâng cấp cái này, ít nhất bạn nên nâng cấp một trong những cái khác cũng như chúng đã làm công việc thực tế. Nếu bạn quan tâm hơn, thay vào đó hãy đọc các câu trả lời khác.

Bạn không nên để lộ khóa chính của cơ sở dữ liệu mà thay vào đó hãy sử dụng khóa thay thế

1. Nếu bạn muốn người dùng của bạn có thể nhớ (ít nhất một chút) hoặc nhận ra định danh của một mục. ( Trả lời của Graystone28s )
2. Nếu bạn muốn lập kế hoạch trước và xem xét rằng bạn có thể thay đổi hệ thống (Cơ sở dữ liệu hoặc cách khác) có thể sẽ thay đổi PK của bạn. ( Trả lời Telastyns )
3. Nếu bạn muốn đảm bảo người dùng của bạn có cách truy cập dữ liệu nhất quán sẽ không thay đổi ngay cả khi công ty của bạn chuyển quyền sở hữu và dữ liệu được chuyển sang một hệ thống hoàn toàn khác. ( Michael Durrant trả lời )
4. Nếu PK của bạn có thể dự đoán được (như một chuỗi), hệ thống của bạn có thể gặp sự cố thu hoạch tài nguyên. ( Trả lời CodeCasters ) Điều này chỉ áp dụng nếu hệ thống của bạn có thông tin đáng để thu hoạch và có thể truy cập được bởi bất kỳ ai hoặc ít nhất là ai đó có lợi ích thu hoạch.

Lưu ý: Khóa được tạo của bạn phải là (loại) con người dễ hiểu ( Trả lời Sqlvogels ).

Nếu hệ thống của bạn không có nhu cầu từ 1. đến 4. thì không có lý do gì để không sử dụng PK cơ sở dữ liệu làm định danh công khai của bạn (một số câu trả lời). Ngoài ra bảo mật không phải là một vấn đề ở đây (một số câu trả lời).

Một lý do tôi đã tìm thấy, trong thời gian đầy đủ mà tôi thấy người dùng cuối yêu cầu rằng số nhận dạng của họ có nghĩa là một cái gì đó (như có tiền tố hoặc chỉ báo của năm mà nó bị chặn). Thay đổi PK là khó, nhưng thay thế dễ dàng hơn nhiều.

Khóa chính của bạn có thể sẽ là thứ bạn muốn lập chỉ mục cơ sở dữ liệu của mình vì lý do hiệu suất và bạn có thể kịp thời vì lý do kỹ thuật thay đổi ví dụ từ số sang hướng dẫn ... bạn không biết lý do công nghệ mới hoặc kiến ​​thức có thể hướng dẫn bạn xuống. Pk của bạn là mục dữ liệu kỹ thuật của bạn, khóa chung dành cho người dùng cuối.

Đối với hầu hết các ứng dụng, điều khá quan trọng là bạn KHÔNG để lộ khóa cho người dùng. Để sử dụng một hệ thống thông tin một cách hiệu quả, người dùng của hệ thống đó thường sẽ cần một cách để xác định thông tin bên trong nó và liên kết thông tin đó với một cái gì đó trên thế giới bên ngoài cơ sở dữ liệu. Trong thuật ngữ cơ sở dữ liệu quan hệ, những định danh là khóa.

Một mẫu thiết kế được sử dụng tốt là tạo ra một khóa "kỹ thuật" bổ sung, hoàn toàn cho các bảng cơ sở dữ liệu như một phương tiện trừu tượng. Ví dụ: để cung cấp khóa ổn định (tương đối không thay đổi) trong đó một số khóa thay thế có thể thay đổi. Các khóa kỹ thuật như vậy thường không được tiếp xúc với người dùng cuối vì làm như vậy sẽ làm suy yếu sự trừu tượng hóa dự định khỏi yêu cầu của người dùng. Nó không có gì để làm với an ninh.

Vấn đề / hiểu lầm tiềm ẩn trong câu hỏi của bạn là do sử dụng không phù hợp thời hạn chính chủ chốt. Khóa chính chỉ là một trong số một số khóa "ứng cử viên" (một số định danh có thể có trong bảng cơ sở dữ liệu). Khóa chính không nhất thiết yêu cầu bất kỳ thuộc tính khác biệt cơ bản nào với bất kỳ khóa nào khác, vì vậy các xác nhận và nguyên tắc thiết kế áp dụng cụ thể cho khóa chính và không áp dụng cho các khóa khác luôn bị nghi ngờ và thường sai.

Cho rằng bạn thường sẽ cần để lộ một khóa cho người dùng của mình, khóa đó nên là gì? Cố gắng làm cho các phím của bạn trở nên quen thuộc, đơn giản và ổn định. Sự quen thuộc và đơn giản làm cho các phím dễ đọc và ghi nhớ và sẽ giúp tránh các lỗi nhập dữ liệu. Ổn định có nghĩa là các thay đổi quan trọng không thường xuyên cũng giúp tránh khả năng xác định sai.

Đây là từ một nhận xét về câu trả lời của Greystone28 bởi CodeCaster. Đây là một ví dụ về những gì bạn đang nói:

Tôi trưng ra InvoiceNumber, có ý nghĩa và có thể thay đổi bởi khách hàng, nhưng tôi cũng tiết lộ InvoiceID, mã mà tôi sử dụng để xác định duy nhất hóa đơn. Bạn không phải (và thường xuyên không muốn) để khóa người dùng là khóa lưu trữ. Câu hỏi này là về sau.

Mục đích nào trong ứng dụng của bạn khi cấp bằng InvoiceID phục vụ?

Bằng cách phơi bày, tôi cho rằng bạn có nghĩa là người dùng có thể nhìn thấy nó. Chỉ hiển thị nó nếu người dùng cần nó để sử dụng ứng dụng của bạn. Nó có thể được sử dụng bởi hỗ trợ kỹ thuật hoặc một số công cụ hành chính. Tôi đã làm việc với một vài ứng dụng làm việc này. Nó làm cho nó dễ dàng hơn để cung cấp hỗ trợ khi tôi biết hồ sơ cụ thể trong câu hỏi.

Điều đó hoàn toàn bình thường đối với các thực thể có một định danh duy nhất được tiếp xúc với thế giới bên ngoài. Đối với một số đối tượng, có thể tìm thấy một mã định danh thực sự có ý nghĩa (ví dụ số hóa đơn) nhưng đối với các đối tượng khác không tồn tại và do đó nó phải được tạo.

Vì mục đích nhất quán và dễ đọc, tôi thấy đó là một cách thực hành tốt cho tất cả các thực thể trong một hệ thống sử dụng cùng loại và tên chính xác cho mã định danh của chúng. Thông thường định danh này sẽ được hiển thị ( <type> getId()) trong một số lớp cơ sở trừu tượng.

Vì lý do tương tự, mỗi dịch vụ trong hệ thống (ví dụ: dịch vụ hóa đơn) nên cung cấp các phương thức giống hệt nhau để truy cập các thực thể bằng mã định danh của chúng. Thông thường phương thức này ( findById(<type> id)) sẽ được kế thừa từ giao diện dịch vụ chung hoặc lớp cơ sở.

Mã định danh này không phải là khóa chính của thực thể nhưng nó có thể là một khóa. Điều duy nhất người ta phải đảm bảo là chiến lược tạo khóa tạo ra các mã định danh duy nhất hợp lý (không cần thiết duy nhất trên toàn cầu nhưng ít nhất là trong hệ thống).

Nếu hệ thống sau đó được di chuyển (lớn nếu theo kinh nghiệm của tôi) sang cơ sở dữ liệu khác thì việc sử dụng một chiến lược khác (không dựa trên các khóa chính) để tạo ra các định danh miễn là chiến lược tương thích với cơ sở dữ liệu ban đầu.

Khóa chính là ở đó, giống như một tay cầm cho bộ dữ liệu (bản ghi, hàng) mà bạn cố gắng truy cập với tư cách là nhà phát triển. Nó cũng được sử dụng trong tính toàn vẹn tham chiếu (ràng buộc khóa ngoài) và có thể nó cũng có một hoặc nhiều trường hợp sử dụng.

Về cơ bản, không có gì xấu khi phơi bày nó cho người dùng, hoặc thậm chí là tin tặc. Bởi vì tôi không biết về một cuộc tấn công sử dụng khóa chính chẳng hạn.

Nhưng trong bảo mật, chúng tôi có nhiều nguyên tắc (chúng tôi chấp nhận và không chấp thuận) và chúng tôi cần tuân thủ chúng:

1. Nguyên tắc cho thuê đặc quyền
2. An ninh thông qua sự tối tăm

Và một số nguyên tắc khác. Những gì họ nói về cơ bản là:

Nếu bạn không cần phải tiết lộ dữ liệu của mình, tại sao bạn lại như vậy?