Làm thế nào tôi có thể ngăn chặn vô tình jacking với cơ sở dữ liệu sản xuất?

31

Mới gần đây, tôi có một nhà phát triển vô tình cố gắng khôi phục cơ sở dữ liệu để sản xuất, khi anh ta đáng lẽ phải khôi phục lại bản sao. Thật dễ dàng để làm, với điều kiện là các tên db tương tự nhau, nghĩa là CustomerName_Staging so với CustomerName_ Producttion.

Lý tưởng nhất là tôi có những thứ này trên các hộp hoàn toàn riêng biệt, nhưng đó là chi phí cấm, và nói đúng ra, nó không ngăn điều tương tự xảy ra nếu người dùng kết nối với hộp sai.

Đây không phải là vấn đề bảo mật, vì đó là người dùng chính xác làm việc với cơ sở dữ liệu dàn dựng và nếu có công việc phải làm trên cơ sở dữ liệu sản xuất, thì đó cũng sẽ là anh ta. Tôi muốn có một nhân viên triển khai để loại bỏ những mối quan tâm đó, nhưng nhóm không đủ lớn cho điều đó.

Tôi muốn nghe một số lời khuyên về thực hành, cấu hình và kiểm soát về cách ngăn chặn điều này.

sql-server best-practices

— Chris B. BehDR
nguồn

25

Các nhà phát triển không nên có quyền truy cập ghi vào cơ sở dữ liệu sản xuất, hoặc tốt nhất là bất kỳ quyền truy cập nào .

— Michael Hampton

12

@MichaelHampton - Đó là tôi và anh ấy. Tôi cũng là một nhà phát triển. Bạn có đề nghị gì?

— Chris B. BehDR

10

Tài khoản người dùng riêng biệt cho từng vai trò (dev vs ops / DBA). Và rất nhiều sự thận trọng.

— Michael Hampton

2

Tôi thực sự khuyên bạn nên có môi trường sản xuất của mình trên một hộp riêng biệt. Mặt khác, dàn và sản xuất phải chia sẻ tài nguyên - đĩa, cpu, v.v. - và nếu dàn là độc quyền một tài nguyên thì môi trường sản xuất của bạn có thể bị ảnh hưởng.

— Thorbjørn Ravn Andersen

1

Chỉ cần có người dùng / mật khẩu riêng biệt cho các cơ sở dữ liệu.

— neutrinus

32

Nếu đây là điều bạn thấy mình làm thường xuyên, hãy tự động hóa nó. Và vì bạn là cả hai nhà phát triển, nên viết một số mã nên có trong nhà xe của bạn. :) Nghiêm túc mặc dù ... bằng cách tự động hóa nó, bạn có thể làm những việc như:

Xác minh rằng bạn đang khôi phục trên đúng máy chủ (nghĩa là không có dev -> prod khôi phục)
Xác minh rằng đó là "loại" cơ sở dữ liệu phù hợp (trong trường hợp của bạn là "dàn dựng" và "sản xuất")
Chỉ ra (các) bản sao lưu nào để khôi phục tự động bằng cách xem các bảng sao lưu trong msdb

Vân vân. Bạn chỉ bị giới hạn bởi trí tưởng tượng của bạn.

— Bến Thul
nguồn

1

Đó là một ý tưởng thú vị ... chúng tôi đã có mã quản lý khôi phục db (để kiểm tra tự động). Chúng ta có thể đặt một lớp trừu tượng ở giữa mà chỉ bao giờ chỉ vào việc dàn dựng để khôi phục lại sản xuất là một quá trình hoàn toàn khác ...

— Chris B. Behlings

11

Bây giờ bạn đang suy nghĩ với cổng. :)

— Ben Thul 7/1/2015

4

Đối với các công việc tự động ảnh hưởng đến sản xuất, tôi muốn thêm vào một bước thủ công yêu cầu người dùng nhập từ "sản xuất" để giảm khả năng họ nghĩ rằng họ đang xem xét, ví dụ như cách dàn dựng.

— Joe Lee-Moyet

2

Tôi được đánh giá thấp vì không ai có quyền truy cập vào sản xuất theo mặc định. Bạn phải có một quy trình đặc biệt để lấy lại mật khẩu prod. Nó là bất tiện nhưng thực sự là tối thiểu.

— OliverS

1

@BenThul Thêm một tài khoản khác để truy cập prod và làm cho nó thêm một bước bất tiện vẫn là giải pháp chính xác cho tôi. Nhu cầu kinh doanh không phải là để DEV tiết kiệm 2 phút mà là khôi phục DB có thể được chuyển hoàn hảo sang tài khoản prod.

— OliverS

32

Tôi không đồng ý với giả định trong câu hỏi vì điều đó là bảo mật, nhưng tôi cũng không đồng ý rằng tự động hóa sẽ tự cứu lấy ngày. Tôi sẽ bắt đầu với vấn đề:

Bạn không thể vô tình làm bất cứ điều gì để sản xuất!

Điều đó bao gồm làm những điều tự động vô tình.

Bạn đang nhầm lẫn bảo mật hệ thống với các khái niệm như "ai được phép làm gì". Tài khoản phát triển của bạn chỉ có thể ghi vào bản sao của chúng, máy chủ kiểm soát phiên bản và cơ sở dữ liệu dev. Nếu họ có thể đọc / ghi sản xuất, họ có thể bị hack và khai thác để đánh cắp dữ liệu của khách hàng hoặc (như bạn đã chứng minh) có thể bị xử lý sai làm mất dữ liệu khách hàng.

Bạn cần bắt đầu bằng cách sắp xếp công việc của bạn.

Tài khoản nhà phát triển của bạn sẽ có thể ghi vào các bản sao của chính họ, kiểm soát phiên bản và có thể kéo từ kiểm soát phiên bản vào môi trường thử nghiệm.
Người dùng sao lưu chỉ có thể đọc từ sản xuất và ghi vào cửa hàng sao lưu của bạn (cần được bảo vệ một cách khéo léo).
Thực hiện bất kỳ đọc / ghi khác trên sản xuất nên yêu cầu xác thực đặc biệt và bất tiện . Bạn không thể truy cập hoặc quên bạn đã đăng nhập. Kiểm soát truy cập vật lý rất hữu ích ở đây. Thẻ thông minh, công tắc lật để "khoanh vùng" tài khoản, truy cập khóa kép đồng thời.

Tiếp cận sản xuất không phải là điều bạn cần làm mỗi ngày. Hầu hết các công việc nên trên nền tảng thử nghiệm của bạn và triển khai ngoài giờ được thực hiện để sản xuất sau khi xem xét kỹ lưỡng. Một chút bất tiện sẽ không giết bạn.

Tự động hóa là một phần của giải pháp.

Tôi không mù quáng về thực tế rằng việc quay vòng đầy đủ (tải lên VCS, kiểm tra vùng phủ sóng, kéo đến máy chủ thử nghiệm, chạy thử nghiệm tự động, xác nhận lại, tạo bản sao lưu, kéo từ VCS) là một quá trình dài.

Đó là nơi tự động hóa có thể giúp đỡ, theo câu trả lời của Ben. Có nhiều ngôn ngữ kịch bản khác nhau giúp cho việc chạy một số tác vụ nhất định trở nên dễ dàng hơn nhiều. Chỉ cần chắc chắn rằng bạn không làm cho nó quá dễ dàng để làm những điều ngu ngốc. Các bước xác nhận lại của bạn vẫn nên được phát âm (và nếu nguy hiểm) chúng sẽ bất tiện và khó thực hiện mà không cần suy nghĩ.

Nhưng một mình , tự động hóa là tồi tệ hơn vô dụng. Nó sẽ chỉ giúp bạn phạm sai lầm lớn hơn với ít suy nghĩ hơn.

Thích hợp cho các đội thuộc mọi quy mô.

Tôi nhận thấy bạn chỉ ra kích thước của đội của bạn. Tôi là một chàng trai và tôi đã vượt qua điều này bởi vì chỉ có một người gặp tai nạn. Có một chi phí nhưng nó đáng giá. Bạn kết thúc với một môi trường sản xuất và phát triển an toàn hơn và an toàn hơn nhiều.

— Ôi
nguồn

2

Ngoài ra, một điều tôi muốn làm là sử dụng hai tài khoản được đặt tên cho mỗi người dùng. Một là dành cho người dùng đăng nhập bình thường, hoạt động, làm việc hàng ngày, v.v., trong khi tài khoản thứ hai (thường có một số hậu tố như dấu + hoặc dấu gạch dưới) có toàn quyền đối với prod và dev mà người dùng yêu cầu. Bằng cách đó, người dùng phải đưa ra quyết định chủ động để đẩy lên sản phẩm trái ngược với dev. Điều này tương tự như viên đạn 3 được mô tả ở trên, nhưng không yêu cầu cơ sở hạ tầng hoặc chi phí bổ sung đáng kể để chứng minh giá trị.

— dùng24313

3

Điều quan trọng nữa là tránh thói quen làm bất cứ điều gì ngoài việc bảo trì sản phẩm trong tài khoản prod của bạn. Cuối cùng, hãy chắc chắn rằng prod không thể xem mã nguồn, không thể khởi động IDE, v.v.

— Eric Lloyd

Tôi có thể lấy một trong những mấu chốt khóa kép đồng thời ở đâu và nó có đi kèm với USB không?

— Lilienthal

Một cái gì đó khác có thể giúp là tự động hóa hoàn toàn các thủ tục (một hoặc hai lần nhấp) trong việc dàn dựng và phát triển, nhưng không hoàn toàn tự động hóa việc triển khai sản xuất. Phải tự điều khiển từ xa vào hộp để làm bất cứ điều gì để sản xuất nhưng không phải với các môi trường khác là một sự khác biệt đáng kể về sự thuận tiện, như bạn đề xuất. (Bạn vẫn có thể tạo ra bất kỳ bước nào liên quan và sử dụng tập lệnh đó trên tất cả các môi trường; ý tôi là bạn sẽ phải tự hủy bỏ việc thực thi các tập lệnh đã nói để sản xuất.) Tất nhiên điều đó có thể được thực hiện ngoài loại xác thực thủ tục bạn đề nghị.

— jpmc26

1

@Lilienthal Đó là một phép ẩn dụ cho nhà hát bảo mật cao nhưng bạn có thể mô phỏng các thanh USB tấn công rẻ tiền đó cho mỗi nhà phát triển và sau đó kiểm tra tự động hóa của bạn ít nhất hai số sê-ri của họ khi chạy những thứ nguy hiểm. Trong các nhóm lớn hơn, sau đó bạn có thể đăng nhập để xem ai đang can thiệp vào sản xuất và giữ đúng người chịu trách nhiệm khi tất cả gặp sự cố.

— Oli

12

Một trong những đồng nghiệp của tôi có một cách tiếp cận thú vị về điều này. Sơ đồ màu thiết bị đầu cuối của mình cho sản xuất là fugly . Xám và hồng và khó đọc, về mặt lý thuyết được cho là để đảm bảo rằng bất cứ điều gì anh ta viết, anh ta thực sự có ý định viết.

Số dặm của bạn có thể thay đổi ... và tôi có lẽ không cần phải nói rằng nó khó có thể tự chống đạn. :)

— áo choàng
nguồn

2

Tôi cũng sử dụng màu nền đỏ lớn trên các kết nối đầu cuối / db đến các máy chủ sản xuất, cũng như hình nền màu đỏ sáng cho các quản trị viên trên PC ...

— Falco

Vâng, tôi đã nghĩ rằng. Làm cho sản xuất xe cứu hỏa thành màu đỏ ...

— Chris B. BehDR

Mã màu giúp. Giống như trong một IDE.

— Thorbjørn Ravn Andersen

1

Các nhà phát triển không nên biết mật khẩu cho cơ sở dữ liệu sản xuất. Mật khẩu prod nên ngẫu nhiên và không dễ nhớ - giống như kết quả của việc trộn bàn phím ( Z^kC83N*(#$Hx). Mật khẩu dev của bạn có thể $YourDog'sNamehay correct horse battery staplehoặc bất cứ điều gì.

Chắc chắn, bạn có thể tìm ra mật khẩu là gì, đặc biệt nếu bạn là một nhóm nhỏ, bằng cách xem tệp cấu hình của ứng dụng khách. Đó là nơi duy nhất tồn tại mật khẩu prod. Điều đó đảm bảo rằng bạn sẽ phải thực hiện một nỗ lực có chủ ý để có được mật khẩu prod.

(Như mọi khi, bạn nên có các bản sao lưu theo thời gian cho cơ sở dữ liệu sản xuất của mình. Ví dụ: với MySQL, lưu trữ nhật ký nhị phân dưới dạng bản sao lưu gia tăng. Đối với PostgreQuery, hãy lưu trữ nhật ký ghi trước. bất kỳ loại thảm họa, tự gây ra hoặc cách khác.)

— 200_success
nguồn

Tôi không thể hoàn toàn đồng ý với điều này, bởi vì trong bất kỳ môi trường lớn thực tế nào cũng có những trường hợp khá thường xuyên mà các nhà phát triển / quản trị viên cần truy cập vào cơ sở dữ liệu sản xuất. Chắc chắn trong một thế giới hoàn hảo với một hệ thống không có lỗi, điều này sẽ không bao giờ xảy ra, nhưng trong hầu hết các hệ thống tôi biết bạn phải sửa một số dữ liệu quan trọng trong sản xuất ... Vì vậy, tôi với Oli, đăng nhập sản xuất nên bất tiện, nhưng khả thi

— Falco

1

@Falco Đó chính xác là những gì tôi đề xuất mặc dù. Bất tiện nhưng khả thi.

— 200_success

Vấn đề với cách tiếp cận của bạn là chỉ, nếu có một trường hợp khẩn cấp và sản xuất bị giảm, thời gian sẽ được tính. Vì vậy, các nhà phát triển của bạn nên biết nơi để tìm mật khẩu và lấy nó nhanh chóng. Nếu họ phải hỏi xung quanh, hãy tìm kiếm các tệp lưu trữ và cấu hình và thử xem bạn đang mất thời gian quý báu = tiền. Vì vậy, tôi muốn có mật khẩu ở một nơi mà mọi người đều biết nơi để tìm, nhưng nó vẫn bất tiện, nhưng nhanh chóng nếu cần

— Falco

2

@Falco Vì môi trường prod sẽ phản ánh chặt chẽ môi trường dev, tệp cấu hình sẽ ở vị trí tương tự trên máy chủ prod như trên máy dev. Bất kỳ nhà phát triển có thẩm quyền nào cũng nên biết tìm ở đâu và nếu họ không biết tìm ở đâu, thì bạn muốn sự chậm trễ đó - chính xác là để ngăn chặn thiệt hại của loại được nêu trong câu hỏi.

— 200_success

Không biết mật khẩu không cản trở tai nạn. Hoàn toàn ngược lại, nó tạo ra động lực để chỉ thực hiện tra cứu mật khẩu một lần và sau đó, nhà phát triển có thể bắt đầu sử dụng lịch sử bash hoặc thậm chí có thể tạo bí danh để kết nối với cơ sở dữ liệu. Và sau đó, tai nạn có nhiều khả năng xảy ra.

— k0pernikus

0

Câu trả lời ngắn gọn là RBAC - kiểm soát truy cập dựa trên vai trò.

Quyền của bạn đối với tất cả các môi trường cần phải khác nhau - và khó chịu như những thứ như UAC, bạn cần chúng: đặc biệt là đối với môi trường SẢN XUẤT.

Có bao giờ một lý do để các nhà phát triển để có thể truy cập trực tiếp đến Prod - bất kể nhỏ cách tổ chức / nhóm là. "Dev" của bạn cũng có thể đội mũ "Giai đoạn" và "Prod", nhưng anh ta cần phải có thông tin và quy trình khác nhau để đạt được các môi trường khác nhau.

Có khó chịu không? Chắc chắn rồi. Nhưng nó [giúp] ngăn chặn làm hỏng môi trường của bạn? Chắc chắn rồi.

— warren
nguồn

0

Một giải pháp nhanh chóng và đơn giản: sử dụng hai tài khoản người dùng khác nhau, một tài khoản cho công việc phát triển bình thường của bạn chỉ có quyền truy cập vào cơ sở dữ liệu phát triển và một tài khoản khác để thực sự hoạt động trên cơ sở dữ liệu sản xuất, với toàn quyền truy cập vào nó. Bằng cách này, bạn sẽ phải chủ động thay đổi tài khoản bạn đang sử dụng trước khi bạn có thể thực hiện bất kỳ thay đổi nào trong sản xuất, điều này đủ để ngăn ngừa các lỗi vô ý.

Cách tiếp cận tương tự có thể được sử dụng nếu bạn có hai trang web, hoặc hai máy chủ hoặc hai môi trường: một tài khoản người dùng để phát triển không có quyền truy cập (hoặc ít nhất là không có quyền truy cập ghi ) vào sản xuất, một tài khoản người dùng khác để làm việc trên hệ thống sản xuất ( S).

Đây là cách tiếp cận tương tự như một sysadmin có tài khoản không phải quản trị viên tiêu chuẩn cho công việc thường ngày (đọc email, lướt web, theo dõi vé, bảng chấm công, viết tài liệu, v.v.) và sử dụng tài khoản quản trị viên đầy đủ riêng biệt khi thực sự hoạt động trên các máy chủ và / hoặc Active Directory.

— Massimo
nguồn