Bảo mật dữ liệu nhạy cảm từ các nhà phát triển

Tôi có một ứng dụng doanh nghiệp đang chạy sử dụng cả kho dữ liệu MySQL và MongoDB . Nhóm phát triển của tôi đều có quyền truy cập SSH vào máy để thực hiện phát hành ứng dụng, bảo trì, v.v.

Gần đây tôi đã gặp rủi ro trong kinh doanh khi người dùng bắt đầu lưu trữ dữ liệu rất nhạy cảm trên ứng dụng mà các nhà phát triển có quyền truy cập gián tiếp vào dữ liệu này gây ra một cơn bão, vì vậy tôi đã được ủy quyền bảo mật dữ liệu để không phải bảo mật dữ liệu. có thể truy cập.

Đối với tôi điều này dường như không thể bởi vì nếu ứng dụng có quyền truy cập vào cơ sở dữ liệu thì một nhà phát triển có quyền truy cập vào máy và nguồn ứng dụng sẽ luôn có thể truy cập dữ liệu.

Bảo mật không phải là cây đũa thần mà bạn có thể vẫy tay khi kết thúc dự án, nó cần được xem xét và xây dựng từ ngày 1. Nó không phải là một ứng dụng, nó là ứng dụng nhất quán của một loạt các giải pháp được áp dụng lặp đi lặp lại và được xem xét thường xuyên là một phần của toàn bộ hệ thống, chỉ mạnh bằng liên kết yếu nhất.

Vì thế, bạn đã đánh dấu một mối quan tâm bảo mật là bước đầu tiên tốt. Bây giờ là tối thiểu bạn phải xác định: -

• Dữ liệu nào bạn đang cố gắng bảo vệ?
• Bạn đang cố gắng bảo vệ dữ liệu đó từ ai?
• Ai thực sự cần truy cập vào những gì (và khi nào)?
• Tác động pháp lý / tài chính / kinh doanh của dữ liệu đó bị xâm phạm là gì?
• Nhu cầu pháp lý / tài chính / kinh doanh cho một người / nhóm có quyền truy cập vào dữ liệu là gì?
• Ngân sách nào mà doanh nghiệp sẵn sàng giao cho chiến lược "lấy an toàn, giữ an toàn" khi trước đây không phải là một yêu cầu kinh doanh?
• Hệ thống cần truy cập gì vào dữ liệu?
• Quá trình này và hệ thống ứng dụng này dựa vào cái gì?
• Điều gì được thực hiện để bảo vệ những môi trường đó?
• Ai sẽ chịu trách nhiệm thực hiện nó và xem xét toàn bộ quá trình?

Cho đến khi bạn biết tất cả những chi tiết bạn thực sự không có gì để làm việc. Thông tin đó sẽ xác định những giảm thiểu nào đối với những mối đe dọa mà bạn có thể (và không thể) áp dụng và tại sao.

Có thể là điều tốt nhất để làm là nhận ra rằng bạn không có trải nghiệm cần thiết và tốt nhất là mang lại cho ai đó mới với trải nghiệm đó. Tôi thường nghe câu trả lời rằng không có ngân sách - nếu nó được coi là thực sự quan trọng thì ngân sách sẽ được tìm thấy.

Bạn đúng rồi. Nếu một ứng dụng có khả năng truy cập nội dung được lưu trữ trên các máy của công ty mà không cần người dùng truyền thêm thông tin mỗi lần , thì các lập trình viên, người bảo trì, sysadins, v.v. của nhà cung cấp dịch vụ có thể truy cập nội dung đó. Điều này về cơ bản là không thể tránh khỏi, và là một nguồn bất an lớn (Edward Snowden là một sysadmin, và có những đặc quyền đặc biệt trên "Bí mật hàng đầu" bởi vì đơn giản là không có cách nào để không cấp chúng.)

Cách duy nhất để tránh điều này là yêu cầu người dùng cung cấp thông tin không bao giờ được cung cấp cho các máy công ty. Điều này thật tẻ nhạt và dễ bị lỗi, vì không ai có thể nhớ đủ thông tin để tạo ra một rào cản truy cập an toàn, và do đó mọi người sẽ ngay lập tức lưu trữ thông tin điện tử của họ ở một nơi nào đó, sau đó sẽ trở thành mục tiêu tấn công mới (và có thể là một mục tiêu yếu hơn mục tiêu bạn đang duy trì). Nhưng nếu bạn muốn khẳng định một cách trung thực "Nhân viên của chúng tôi không có khả năng truy cập nội dung của người dùng" thì đó là cách duy nhất.

(Cũng lưu ý rằng một mô hình kinh doanh như vậy dường như đang trở nên khó kiểm soát về mặt chính trị. Các doanh nghiệp đã bị các dịch vụ bảo mật buộc phải ngừng hoạt động vì cố gắng thực hiện chính xác điều này. Tôi hiểu rằng việc đảm bảo quyền riêng tư có giá trị kinh doanh, nhưng nó không thể có nhiều hơn giá trị kinh doanh hơn mục tiêu cơ bản là ở lại trong kinh doanh.)

Bạn khá đúng; một số nhà phát triển sẽ luôn cần quyền truy cập vào dữ liệu Live, nếu chỉ để chẩn đoán các vấn đề sản xuất. Điều tốt nhất bạn có thể làm là hạn chế thiệt hại tiềm tàng bằng cách giảm số lượng người tham gia.

With great power comes great ... opportunity to really, *really* foul things up. 

Nhiều nhà phát triển sẽ không muốn trách nhiệm đó và những người khác, sẽ không "sẵn sàng" nắm giữ nó, và vì vậy không nên có.

Câu hỏi: Tại sao nhóm Phát triển của bạn thực hiện phát hành trực tiếp ?
Tôi sẽ đề nghị bạn cần một "nhóm" Quản lý phát hành (thậm chí đó chỉ là một tập hợp con trong nhóm của bạn, cộng với đại diện Doanh nghiệp để đưa ra bất kỳ "quyết định" nào trong ngày, như "Đi / Không đi")? Điều này sẽ loại bỏ phần lớn "nhu cầu" cho các nhà phát triển để chạm vào bất cứ thứ gì Live.

Bạn có bất kỳ loại thỏa thuận không tiết lộ / bảo mật giữa các nhà phát triển và công ty không? Nó nặng tay, nhưng nó có thể có một số công đức.

Vấn đề là các nhà phát triển của bạn có quyền truy cập vào hệ thống. Nếu họ cần dữ liệu sản xuất để gỡ lỗi thì hãy cung cấp cho họ kết xuất cơ sở dữ liệu trong đó tất cả thông tin nhạy cảm đó sẽ bị xóa. Sau đó, các nhà phát triển có thể làm việc với bãi chứa đó.

Triển khai một phiên bản mới không nên liên quan đến bất kỳ nhà phát triển nào - đó là một nhiệm vụ quản trị thuần túy, hoặc thậm chí tốt hơn - một nhiệm vụ hoàn toàn tự động. Cũng cần lưu ý về việc phát hành và triển khai là hai nhiệm vụ rất khác nhau. Nếu quy trình của bạn không nhận thức được điều đó thì hãy thay đổi nó cho phù hợp.

Quy tắc số 1 về bảo mật: Nếu ai đó có quyền truy cập thông tin, họ có quyền truy cập vào thông tin đó

Tautology đó là gây phiền nhiễu, nhưng đó là sự thật. Nếu bạn cấp quyền truy cập cho một cá nhân, họ có quyền truy cập vào dữ liệu. Đối với người dùng, điều này thường có nghĩa là kiểm soát truy cập, nhưng đối với các nhà phát triển ... à ... họ là những người phải viết điều khiển truy cập.

Nếu đây là một vấn đề lớn đối với bạn (và có vẻ như nó là như vậy), hãy xem xét xây dựng bảo mật vào phần mềm của bạn. Một mô hình phổ biến là thiết kế phần mềm bảo mật theo lớp. Ở lớp thấp nhất, một nhóm phát triển đáng tin cậy thiết kế phần mềm quản lý kiểm soát truy cập trần trụi nhất. Phần mềm đó được xác nhận và xác minh bởi càng nhiều người càng tốt. Bất cứ ai thiết kế mã đó đều có quyền truy cập vào mọi thứ, vì vậy niềm tin là điều cần thiết.

Sau đó, các nhà phát triển có thể xây dựng kiểm soát truy cập linh hoạt hơn trên lớp lõi đó. Mã này vẫn phải là V & Vd, nhưng nó không nghiêm ngặt vì bạn luôn có thể dựa vào lớp lõi để bao quát các yếu tố cần thiết.

Các mô hình mở rộng ra bên ngoài.

Phần khó, thực sự là nghệ thuật thiết kế các hệ thống này, là làm thế nào để xây dựng từng lớp để các nhà phát triển có thể tiếp tục phát triển và gỡ lỗi trong khi vẫn cung cấp cho công ty của bạn sự bảo mật mà bạn mong đợi. Cụ thể, bạn sẽ cần phải chấp nhận rằng việc gỡ lỗi đòi hỏi nhiều đặc quyền hơn bạn nghĩ và việc cố gắng khóa nó sẽ dẫn đến một số nhà phát triển rất tức giận.

Là một giải pháp phụ, hãy xem xét việc tạo cơ sở dữ liệu "an toàn" cho mục đích thử nghiệm, nơi các nhà phát triển có thể tách ra tất cả các cơ chế an toàn và thực hiện gỡ lỗi nghiêm trọng.

Cuối cùng, cả bạn và nhà phát triển của bạn cần hiểu một nguyên lý bảo mật chính: Tất cả bảo mật là sự cân bằng giữa bảo mật và khả năng sử dụng. Bạn phải đạt được số dư của mình như một công ty. Hệ thống sẽ không hoàn toàn an toàn và nó sẽ không thể sử dụng được. Sự cân bằng đó thậm chí sẽ di chuyển khi công ty của bạn phát triển và / hoặc nhu cầu đối với các nhà phát triển thay đổi. Nếu bạn cởi mở với thực tế này, bạn có thể giải quyết nó.

Thiết lập hai triển khai của ứng dụng cũng sử dụng các triển khai cơ sở dữ liệu riêng biệt. Một là triển khai sản xuất và một là triển khai thử nghiệm.

Việc triển khai thử nghiệm chỉ nên có dữ liệu thử nghiệm. Đây có thể là dữ liệu giả tưởng được tạo ra cho mục đích đó hoặc là bản sao của dữ liệu sản xuất được ẩn danh để ngăn các nhà phát triển tìm ra người thật và thực thể đằng sau dữ liệu.

Trong hai công ty tài chính, các nhà phát triển không có quyền truy cập vào máy sản xuất. Tất cả các yêu cầu sửa đổi máy sản xuất phải trải qua một quy trình phê duyệt, với một kịch bản và được các nhà quản lý phê duyệt. Nhóm dev-op đã hoàn thành việc triển khai thực tế. Tôi cho rằng nhóm này chỉ là nhân viên và đã thông qua kiểm tra lý lịch. Họ cũng không có kiến ​​thức về nhà phát triển nên có lẽ không thể rình mò nếu họ muốn. Ngoài ra, bạn sẽ mã hóa tất cả các mục cơ sở dữ liệu bằng khóa bí mật được lưu trữ trong các biến môi trường. Ngay cả khi các cơ sở dữ liệu bị rò rỉ công khai, không ai có thể đọc nó. Khóa này có thể được bảo vệ bằng mật khẩu (PBKDF) để chỉ người điều hành mới có thể mở khóa. Hệ thống của bạn có thể yêu cầu mật khẩu điều hành khi khởi động (hoặc nhiều khả năng được ủy quyền cho nhà phát triển hoặc người quản lý nhà phát triển). Về cơ bản, chiến lược là phân tán kiến ​​thức để một khối lượng kiến ​​thức cần thiết không tồn tại ở một người và có sự kiểm tra và cân bằng. Đây là cách Coca-Cola bảo vệ công thức của mình. Thành thật mà nói, một số câu trả lời là cop-outs.

MongoDB có các kiểm soát bảo mật hạn chế và phụ thuộc vào môi trường an toàn. Liên kết với một ip và cổng cụ thể (và ssl kể từ 2.2) và xác thực thô, đó là những gì nó cung cấp. MYSQL thêm GRANT o ON db.t TO ... Dữ liệu ở phần còn lại không được mã hóa và ssl không được sử dụng theo mặc định. Tạo hàng rào. Truy cập chỉ đọc cho nhà phát triển vào các tệp nhật ký liên quan đến ứng dụng là đủ để gỡ lỗi. Tự động hóa vòng đời ứng dụng.

Ansible đã giúp chúng tôi tự động hóa các hoạt động tiêu chuẩn (triển khai, nâng cấp, khôi phục) trên nhiều môi trường đơn lẻ trong khi sử dụng các kho tiền được mã hóa riêng biệt để lưu trữ các biến môi trường nhạy cảm như máy chủ, cổng và thông tin đăng nhập. Nếu mỗi kho tiền chỉ có thể được giải mã bởi các vai trò khác nhau và chỉ trên một máy chủ pháo đài, đối với các hoạt động được ghi lại, thì khả năng kiểm toán cung cấp bảo mật chấp nhận được. Nếu bạn cấp SSH, thì vui lòng sử dụng selinux để tránh giả mạo khóa, sử dụng máy chủ pháo đài với xác thực ldap / kerberos để quản trị và sử dụng sudo một cách khôn ngoan.