Làm thế nào để bạn giới hạn quyền truy cập vào môi trường sản xuất trong công ty bạn làm việc?


8

Trong công ty tôi làm việc, các kỹ sư sùng đạo (hiện chỉ có 2 thành viên, là tôi và một đồng nghiệp khác) là những người duy nhất có quyền truy cập vào cơ sở dữ liệu sản xuất.

Vì vậy, khi bất kỳ nhà phát triển khác cần thực hiện một truy vấn MySQL trên cơ sở dữ liệu sản xuất. Họ sẽ gửi truy vấn đến 2 kỹ sư để cho họ thực hiện nó.

Dưới đây là các tình huống khi chúng ta cần thực thi các lệnh đến cơ sở dữ liệu sản xuất:

  1. Cơ sở dữ liệu chứa dữ liệu bị hỏng, tạo ra lỗi. Họ thực hiện các lệnh để sửa lỗi.

  2. Một lỗi được báo cáo. Và họ muốn xem các giá trị hiện tại bên trong cơ sở dữ liệu.

  3. Một trong những khách hàng của chúng tôi muốn sửa đổi dữ liệu của anh ấy / cô ấy. Nhưng ứng dụng web của chúng tôi không có khả năng sửa đổi. Vì vậy, chúng tôi phải gửi các lệnh MySQL trực tiếp đến cơ sở dữ liệu để hoàn thành yêu cầu của khách hàng.

  4. Nhóm QA đã tạo các tài khoản thử nghiệm trên môi trường sản xuất. Và họ muốn thay đổi trạng thái của tài khoản để họ có thể thực hiện các thử nghiệm khác.

Điều này tạo ra rất nhiều gián đoạn cho tôi các đồng nghiệp khác. Khi chúng tôi phát triển các chương trình vào ban ngày, chúng tôi thường phải chuyển ngữ cảnh chỉ để thực hiện một số truy vấn.

Tôi không nghĩ rằng đây là một kiến ​​trúc tốt cho công ty. Làm thế nào để bạn kiểm soát các quyền đối với môi trường sản xuất trong công ty của bạn?

Cơ sở dữ liệu sản xuất của chúng tôi bao gồm thông tin khách hàng nhạy cảm. Nếu dữ liệu bị rò rỉ ra ngoài, công ty chúng tôi có thể bị phạt hàng triệu đô la.

Câu trả lời:


5

Nếu câu hỏi của bạn là làm thế nào để quản lý các thay đổi cơ sở dữ liệu, hãy xem xét một cái gì đó như Flyway . Điều này cho phép bạn kiểm soát các thay đổi của mình thông qua các tệp cấu hình được theo dõi trong kho lưu trữ của bạn và áp dụng chúng thông qua quy trình tự động & được kiểm soát - sử dụng các bước xem xét và quảng cáo mã thông thường.

Nếu câu hỏi là "làm cách nào để các nhà phát triển ngừng làm phiền tôi để chạy các lệnh SQL tùy ý" thì bạn có thể muốn xem xét việc tạo kịch bản để tự động hóa hoặc cung cấp cho họ UI của bên thứ 3 để sử dụng với tài khoản bị khóa để ngăn chặn thay đổi và hạn chế họ nhìn thấy bất kỳ bảng nhạy cảm. YMMV tùy thuộc vào cách bố trí DB của bạn.


Câu hỏi của tôi là về how do I get devs to stop bugging me to run arbitrary SQL commands. Tôi nghĩ rằng tôi có thể sử dụng ProxyQuery để che giấu dữ liệu khách hàng nhạy cảm để các nhà phát triển khác có thể đọc cơ sở dữ liệu sản xuất.
Brian

Bạn đang cố gắng để giữ cho chúng khỏi làm hỏng hoặc nhìn thấy dữ liệu nhạy cảm ? Trước đây bạn có thể cung cấp cho họ quyền truy cập RO với một cái gì đó như mysql-web-ui. Thứ hai sẽ yêu cầu RBAC như được nêu trong câu trả lời của Phil W.
TheFiddlerWins

4

Bạn có thể nhúng lược đồ cơ sở dữ liệu và thay đổi dữ liệu vào kiểm soát mã nguồn bằng cách sử dụng khái niệm được gọi là di chuyển cơ sở dữ liệu. Chúng sau đó có thể được thực thi trên các môi trường dev và staging như là một phần của quy trình triển khai tự động một phần.

Ví dụ: trong môi trường của tôi (ứng dụng Web PHP), tôi đang sử dụng Lược đồ tài liệu để cập nhật lược đồ, di chuyển Yii2 để thay đổi dữ liệu. Các lệnh tương ứng là một phần của tập lệnh bash 7 dòng chạy tất cả các lệnh cần thiết để triển khai thay đổi trong từng môi trường


3

Tôi thấy một vấn đề đầu tiên, DevOps là về việc xây dựng các nhóm có thể xử lý một ứng dụng từ xây dựng đến khai thác.
Vì vậy, các nhà phát triển của bạn nên có quyền truy cập vào cơ sở dữ liệu, bạn đã trích dẫn nhiều trường hợp khác nhau, đó là thực tế của nhiều người và nhược điểm lớn đang khiến bạn và đồng nghiệp gặp khó khăn cũng như cản trở công việc của chính bạn.

Các câu trả lời khác giải quyết tốt việc thay đổi lược đồ hoặc thay đổi theo kế hoạch thực sự sẽ được tích hợp như một phần của quy trình phân phối ứng dụng, nhưng chúng không cho phép khắc phục nhanh nhu cầu truy cập trực tiếp, khi một nhà phát triển có thể cần phải bỏ DB để hiểu nguyên nhân gây ra lỗi và cách khắc phục nó cho ví dụ.

Những thứ như ProxyQuery mà bạn đã trích dẫn trong một nhận xét có thể ổn đối với cơ sở dữ liệu MySQL, chỉ cần cấu hình MySQL để ghi nhật ký cũng có thể là một cách tiếp cận tốt, MySQL cung cấp một plugin kiểm toán thương mại có thể trả lời vấn đề cho phép các nhà phát triển của bạn truy cập cơ sở dữ liệu và thực hiện CISO yêu cầu theo dõi những gì được thực hiện.

Nếu bạn có nhiều hơn chỉ là Mysql DB và cần kiểm tra quyền truy cập của họ, việc định cấu hình từng hệ thống để kiểm tra hành động của người dùng nhật ký và không phải hành động ứng dụng có thể khó khăn. Giữ mọi thứ đóng lại có thể còn tồi tệ hơn, một ngày nào đó sẽ tích hợp vỏ DB trong một ứng dụng để phá vỡ khối đường này và cuối cùng nó sẽ đi vào sản xuất mà không có kiểm soát truy cập thích hợp và để lộ tất cả dữ liệu, tôi khuyên bạn nên hỏi công ty để xem xét chính sách này.

Có một giải pháp thương mại mà tôi biết có thể giúp (và cho phép kiểm toán nhiều hơn chỉ các yêu cầu DB) đó là mạnh mẽ , nó cũng cho phép kiểm tra các phiên ssh và rdp, vì nếu các nhà phát triển của bạn cần truy cập vào DB, họ cũng có thể cần quyền truy cập vào máy lưu trữ các ứng dụng cho mục đích gỡ lỗi.


0

... Tôi và một đồng nghiệp khác ... là những người duy nhất có quyền truy cập vào cơ sở dữ liệu sản xuất.

Đó là một vị trí khởi đầu tốt.
Rất thường xuyên, các DBA thấy mình cố gắng đóng cánh cửa ổn định sau khi con ngựa đã chạy đi.

Vì vậy, khi bất kỳ nhà phát triển nào khác cần thực hiện truy vấn MySQL trên cơ sở dữ liệu sản xuất ...

Câu hỏi:
Tại sao Nhà phát triển chạy bất cứ thứ gì chống lại cơ sở dữ liệu Sản xuất?

Làm thế nào để bạn kiểm soát các quyền đối với môi trường sản xuất trong công ty của bạn?

Kiểm soát truy cập dựa trên vai trò.

Người dùng được cấp quyền truy cập vào từng cơ sở dữ liệu và khi vai trò công việc của họ yêu cầu và Vai trò được sử dụng để cấp cho họ quyền truy cập vào các bảng trong mỗi cơ sở dữ liệu. Quá trình mà các tài khoản này được tạo và các vai trò được cấp được quản lý tập trung và kiểm toán chặt chẽ.

Các nhà phát triển không bao giờ nên "thực hành", cập nhật quyền truy cập bên ngoài cơ sở dữ liệu Phát triển của họ. Mọi thứ khác nên được viết kịch bản, thử nghiệm, kiểm toán và phát hành thông qua các kênh được chuẩn bị trước, kiểm soát (và tốt nhất là tự động).

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.