Các nhà phát triển nên có bao nhiêu quyền truy cập cơ sở dữ liệu? [đóng cửa]

Vì vậy, tôi đã làm việc ở nhiều nơi làm việc khác nhau với tư cách là nhà phát triển và mức độ truy cập vào cơ sở dữ liệu của tôi đã thay đổi. Tôi thường không có quyền truy cập db sản xuất.

Hầu hết thời gian tôi có quyền truy cập vào cơ sở dữ liệu thử nghiệm, nhưng nó khác nhau. Đôi khi tôi có thể làm và thay đổi cơ sở dữ liệu và dữ liệu theo ý muốn, nhưng thường có những sắp xếp khác. Giống như tôi chỉ có thể có quyền truy cập đọc vào dữ liệu.

Tôi đã làm việc ở một nơi mà một nhóm DBA sẽ quản lý cơ sở dữ liệu, chúng tôi không thể thay đổi gì cả trừ khi chúng tôi gửi một biểu mẫu với tập lệnh sql để họ "kiểm tra". Họ thường không có nhiều liên quan đến bản thân dự án nên hầu hết thời gian, đó chỉ là nhấn F5.

Thành thật mà nói, tôi có thể hiểu tại sao prod cần phải bị khóa nhưng tôi thích có nhiều quyền truy cập cơ sở dữ liệu hơn trong môi trường dev và test. Tôi nghĩ rằng hầu hết các nhà phát triển có khả năng hợp lý để biết cách của họ xung quanh một cơ sở dữ liệu. Nhưng tôi muốn nghe ý kiến ​​mặc dù? Các nhà phát triển nên có bao nhiêu quyền truy cập cơ sở dữ liệu? Chúng ta có thể được tin tưởng để không phá vỡ bất cứ điều gì trên đó?

Các nhà phát triển cần đọc quyền truy cập vào tất cả các cơ sở dữ liệu bao gồm cả prod. Đôi khi vấn đề là dữ liệu trên Prod không phải là những gì họ mong đợi và họ cần xem dữ liệu gây ra sự cố vì họ không thể sao chép nó trên dev.

Các nhà phát triển không nên có quyền ghi dữ liệu sản xuất hoặc quyền để tạo đối tượng. Không có gì nên được prod mà không phải là một phần của bản phát hành chính thức. Đã rất nhiều lần, mọi người sửa lỗi nhanh với prod mà không hoạt động, khiến prod thậm chí còn bị làm phiền hoặc hoạt động nhiều hơn nhưng họ quên đặt mã vào máy chủ dev / QA / Staging và thậm chí tệ hơn vào nguồn kho lưu trữ kiểm soát và mã được ghi đè khoảng một tháng sau trong bản phát hành chính thức tiếp theo.

Tôi thích các nhà phát triển có quyền QA cơ sở dữ liệu đầy đủ vì việc triển khai đến một máy chủ khác giúp họ xem liệu có bất kỳ lỗ hổng nào trong quá trình triển khai của họ không (oops quên rằng tôi đã thay đổi bảng đó để làm như vậy và rất tiếc tôi đã quên rằng tôi đã thay đổi sử dụng GUI và không phải trong tập lệnh trong điều khiển nguồn, đó là cách mà bất kỳ thay đổi cấu trúc cơ sở dữ liệu nào cần phải xảy ra).

Khi bạn có một máy khách kiểu Doanh nghiệp mới, người sẽ có bộ máy chủ của riêng họ, các quyền có thể được nới lỏng trước khi đi vào hoạt động. Điều này là do rất nhiều nhu cầu xảy ra và một số ít người có thể làm cho nó xảy ra trên prod đã bị tồn đọng và đôi khi thậm chí cần phải nghỉ ngơi. Cụ thể, những người đang nhập dữ liệu từ một hệ thống khác, có thể được giao nhiệm vụ đưa chúng lên prod trước khi khởi chạy nếu tải dữ liệu sẽ mất nhiều thời gian. Những người này có xu hướng trở thành chuyên gia dữ liệu và có mức độ thoải mái cao hơn khi cho phép họ truy cập tạm thời vào sản phẩm so với nhà phát triển ứng dụng trung bình. Đây không phải là một thứ xa xỉ mà bạn có khi đến một máy chủ sản xuất trực tiếp.

Một trong những điều quan trọng nhất về việc giới hạn quyền sản xuất đối với cơ sở dữ liệu là các nhà phát triển sau đó cần đảm bảo công việc của họ ở dạng có thể được triển khai bởi người khác. Điều này có xu hướng cải thiện chất lượng công việc vì họ không cố gắng sửa lỗi vì họ đã quên một cái gì đó hoặc một cái gì đó không hoạt động vì họ đã làm nó khác với prod hơn là chỉ dựa vào bộ nhớ. Bạn cũng mất các "oops Tôi đã xóa toàn bộ bảng người dùng một cách tình cờ vì tôi quên làm sáng tỏ một mệnh đề where" khi các triển khai prod hoàn toàn sử dụng các tập lệnh chạy toàn bộ không phải một lệnh tại một thời điểm như điển hình khi các nhà phát triển chạy mọi thứ trên prod. Một nhóm có quyền hạn chế đối với cơ sở dữ liệu prod có nhiều khả năng lưu trữ các thay đổi cơ sở dữ liệu trong kiểm soát nguồn.

Vâng, đây thực sự là một câu hỏi về "Ma cà rồng (Lập trình viên) so với Người sói (Sysadmin)" khi Jeff Atwood đã đặt nó ở đây .

Thông thường (điều đó có nghĩa là có sự xa xỉ để thiết lập một môi trường đầy đủ), nhà phát triển truy cập vào:

• Máy chủ sản xuất
  • Không có (SA / PM sẽ áp dụng cho thiết lập lược đồ, người dùng cuối sẽ cung cấp dữ liệu init)
• Máy chủ UAT
  • Không có (SA / PM sẽ áp dụng cho thiết lập lược đồ và gieo dữ liệu mẫu)
• Máy chủ thử nghiệm / QA
  • Thông thường, nhà phát triển sẽ gửi tập lệnh thiết lập lược đồ cho nhóm QA và QA tạo các bảng
  • Các nhà phát triển có quyền truy cập đầy đủ vào cơ sở dữ liệu nhưng hiếm khi thay đổi nó
  • Các nhà phát triển có thể giúp các đồng nghiệp QA gieo / vá / xóa một số dữ liệu
• Máy chủ phát triển / localhost
  • Truy cập đầy đủ

Lý do chính đằng sau lý do tại sao các nhà phát triển không nên chạm vào các máy chủ sản xuất là: khi có sự cố xảy ra, nhóm vận hành chịu trách nhiệm, nhưng không phải là nhà phát triển.

Tối thiểu tuyệt đối bạn cần để hoàn thành công việc.

Nếu tất cả các nhà phát triển được cấp quyền truy cập DB đầy đủ, khả năng một người tức giận (hoặc say rượu, hoặc cực kỳ mệt mỏi hoặc ...) và gây thiệt hại nghiêm trọng sẽ cao hơn nhiều nếu họ chỉ có thể đọc từ cơ sở dữ liệu.

Nếu công việc của bạn chủ yếu có thể được thực hiện mà không có quyền truy cập ghi DB (Và chủ yếu là ý tôi là nhiều nhất là một vài yêu cầu thay đổi một tuần), thì bạn thực sự không cần truy cập ghi.

Có 2 mong muốn cạnh tranh trong tất cả các môi trường làm việc.

• Mong muốn cung cấp cho mọi người quyền truy cập để họ có thể tự giải quyết vấn đề. Điều này cho phép họ được nhanh chóng và tự phục vụ.
• Mong muốn giới hạn và kiểm soát truy cập để ngăn ngừa thiệt hại, giảm thời gian hoặc mất dữ liệu (cố ý hoặc cách khác).

Một phần của những gì định hình sự cân bằng được đánh (hoặc dù sao đi nữa) là kỳ vọng được đặt ra cho các nhà phát triển. Trong mọi công việc tôi đã có nơi các nhà phát triển có quyền truy cập vào mọi thứ mà họ kỳ vọng là họ sẽ tự giới hạn. Chỉ truy cập hệ thống nếu bạn biết bạn đang làm gì. Điều đó có nghĩa là bạn biết những gì bạn đang làm từ cả quan điểm của nhà phát triển và sysadmin. Nếu bạn không chắc chắn ở bất kỳ khu vực nào, bạn sẽ không có doanh nghiệp truy cập vào hệ thống mà không có ai đó làm việc với bạn.

Để tổng hợp nếu bạn không biết, bạn không nên truy cập vào bất kỳ hệ thống nào ngoài các hệ thống dev có thể xây dựng lại dễ dàng . Nếu bạn biết, hơn bạn biết bạn không nên truy cập bất kỳ hệ thống nào ngoại trừ các hệ thống dev dễ xây dựng lại của bạn .

Các nhà phát triển nên có quyền truy cập đầy đủ vào cơ sở dữ liệu dev (lý tưởng nhất là họ nên chạy một máy chủ cục bộ, nhưng điều đó không phải lúc nào cũng có thể). Họ nên có quyền truy cập vào cơ sở dữ liệu xây dựng / QA, nhưng chỉ với dữ liệu (phải có sự cho phép / gửi một vé để thay đổi cấu trúc). Các nhà phát triển không bao giờ có quyền truy cập ngẫu nhiên vào cơ sở dữ liệu sản xuất (trừ khi đó là một công ty / dự án nhỏ và các nhà phát triển cũng hỗ trợ sản xuất).

Tôi nghĩ chìa khóa ở đây là mức độ trách nhiệm của các nhà phát triển. Trong một tổ chức lớn có nhiều nhà phát triển, họ có thể sẽ chỉ có quyền truy cập vào phát triển với quyền truy cập chỉ đọc vào QA / Test.

Tuy nhiên, cần có những người trong nhóm phát triển có quyền truy cập đầy đủ vào tất cả các môi trường. Đây thường là người chịu trách nhiệm sửa lỗi, v.v. .

Tôi đã làm việc trong một cửa hàng CNTT lớn và chúng tôi đã đọc được quyền truy cập vào sản xuất cho hầu hết mọi người. Tôi là nhà phát triển chính cũng có quyền đối với cơ sở dữ liệu sản xuất. Tôi vẫn phải tuân theo các hướng dẫn tương tự như các hệ thống quản trị hệ thống và các DBA về quy trình và giấy tờ, nhưng tôi cũng có thể khắc phục khẩn cấp nếu cần.

Có một vấn đề liên quan mà hầu hết chúng ta đều quên - chúng ta có thể không phải là người duy nhất sử dụng cơ sở dữ liệu! Chúng ta có xu hướng coi điều này là đương nhiên nhưng không nên. Ngay cả các trang web nhỏ cũng có thể có những người kinh doanh chạy các công cụ của bên thứ ba chống lại cơ sở dữ liệu cho các báo cáo của họ. Các trang web doanh nghiệp hầu như sẽ luôn có nhiều người dùng các bảng cơ sở dữ liệu và thay đổi 'nhỏ' của bạn có thể phá vỡ các ứng dụng của họ và ngược lại.

Vì vậy, đây phải là câu hỏi đầu tiên. Thứ hai phải là đội ngũ nhân viên sẵn sàng - Tôi đã làm việc tại các trang web có hệ thống quản lý hệ thống bảo vệ sân cỏ của họ nhưng thực sự không tốt lắm. (Đó có lẽ là lý do tại sao họ rất lãnh thổ - họ biết rằng họ sẽ bị nóng nhiều nếu có ai đó nhìn xung quanh.) Đôi khi bạn phải có nhiều quyền truy cập hơn bạn muốn.

Nhưng trong một thế giới lý tưởng, tôi đồng ý với những quan điểm của người khác. Tôi không muốn truy cập vào dữ liệu trực tiếp, thật lòng mà nói, tôi không muốn chịu trách nhiệm. Hãy suy nghĩ về điều đó - nếu tôi có quyền truy cập hoạt động và có vi phạm thì tôi sẽ phải dành nhiều thời gian để chứng minh rằng tôi không có gì để làm với nó. Tôi có thể phải chứng minh rằng tôi đã không đánh cắp dữ liệu vì lý do cá nhân, v.v ... Rất nhiều trang web rất coi trọng quyền riêng tư, đặc biệt. trang web chính phủ.

Tôi thậm chí không muốn truy cập ghi / quản trị viên vào hệ thống của nhóm thử nghiệm. Nếu tôi không thể làm gì đó trên hệ thống sản xuất thì tôi không muốn làm điều đó trên các hệ thống thử nghiệm. Truy cập đọc là ngoại lệ vì nó cần thiết để tìm hiểu những gì đang xảy ra.

Hệ thống phát triển, cả cá nhân và phòng ban, là một câu chuyện khác nhau. Nhưng ngay cả ở đây, trong thực tế, tốt nhất là chạy tất cả các thay đổi cơ sở dữ liệu thông qua một người điểm thay vì để mọi người làm việc của riêng họ.

Tôi hoàn toàn đồng ý với tất cả câu trả lời, nói rằng "càng ít đặc quyền càng tốt cho các nhà phát triển trên cơ sở dữ liệu prod". Nhưng thành thật mà nói, ai có thể từ chối các nhà phát triển truy cập vào cơ sở dữ liệu nếu họ muốn có được nó. Với đủ ý chí (có thể là tội phạm hoặc tốt) họ sẽ có được quyền truy cập cần thiết.

Ai có thể ngăn họ đưa trình soạn thảo SQL đơn giản vào ứng dụng? Bằng cách này, họ có thể sử dụng cơ sở dữ liệu với các đặc quyền của ứng dụng. Trong hầu hết các trường hợp, đây là tất cả những gì cần thiết. Khi cơ sở dữ liệu được cấu hình an toàn, chúng có thể không có đặc quyền để tạo hoặc xóa các đối tượng, nhưng ít nhất chúng có quyền truy cập đọc và ghi vào dữ liệu.

Tôi đã ở đây các ops mọi người khóc. Nhưng hãy thành thật với chính mình, bạn không hoàn toàn kiểm soát ứng dụng được triển khai trong sản xuất, trừ khi bạn tự viết nó (và thậm chí sau đó, không nghĩ về các thư viện). Và với tất cả các nhà phát triển, như Erin đã nói, bạn cũng chịu trách nhiệm cho môi trường sản xuất, không chỉ những người làm việc. Vì vậy, sử dụng đặc quyền của bạn một cách khôn ngoan.