Cassandra qua VPN: tách quyền truy cập cho máy khách và nút

Một triển khai Cassandra không có một mạng cơ sở dữ liệu chung duy nhất. Ứng dụng nói chuyện với dịch vụ máy khách, các thành viên cụm nói chuyện với nhau, và người vận hành dùng giao diện quản trị, và ba nhóm người dùng đó không nên thừa hưởng khả năng tiếp cận của nhau. Một đường riêng như VPN là điểm khởi đầu tốt, nhưng nó không phải danh tính người dùng của cơ sở dữ liệu và cũng không phải chính sách mã hóa của nó. Hãy coi quyết định về kết nối và quyết định về ủy quyền là hai lần rà soát riêng biệt.

Mỗi nhóm trong ba nhóm có câu trả lời riêng, và các mục dưới đây xem xét chúng theo thứ tự phơi nhiễm.

Ba nhóm người dùng, ba quyết định

Xác định điều mỗi nhóm thực sự cần trước khi chạm vào một quy tắc. Máy khách cần trình lắng nghe máy khách và đủ thông tin để tới mọi nút có thể được cấp cho chúng, nút đồng cấp cần nhau trên cổng internode, và người vận hành cần giao diện quản lý cho những gì runbook thực sự yêu cầu. Ba danh sách, ba nhóm người dùng, ba mức tin cậy.

Sai lầm phổ biến là xây một phân đoạn riêng phẳng và cho rằng ranh giới VPN làm phần còn lại. Bên trong nó, một ứng dụng tới được cổng máy khách thường cũng tới được cổng internode, và các công cụ quản trị của người vận hành thường nằm trên cùng máy nhảy với ứng dụng. Làm phẳng chúng cùng nhau nghĩa là một danh tính ứng dụng bị xâm phạm đã có phạm vi tiếp cận lớn hơn các truy vấn của chính nó. Hãy vẽ ba nhóm người dùng thành ba hàng trong tài liệu thiết kế, mỗi hàng kèm quy tắc cho phép nó, và các lỗ hổng sẽ trở nên rõ ràng trước khi ai đó xây chúng.

Máy khách cần gì, và không gì hơn

Cho phép các nguồn ứng dụng dự định tới các điểm cuối máy khách của phiên bản đã triển khai, và giữ các dịch vụ cụm và quản lý không liên quan ra ngoài phạm vi đó. Sau đó kiểm tra cách trình điều khiển khám phá các nút. Một điểm liên hệ đầu tiên tiếp cận được không chứng minh rằng mọi địa chỉ nút mà trình điều khiển chọn sau đó đều tiếp cận được từ ngữ cảnh máy khách đó, vì trình điều khiển hỏi cụm về các nút đồng cấp rồi kết nối tới những địa chỉ mà cụm quảng bá.

Đó là lý do một sự không khớp địa chỉ riêng tạo ra mẫu quen thuộc: kết nối đầu tiên thành công rồi đến hết thời gian chờ. Hãy cấu hình địa chỉ quảng bá và định tuyến máy khách một cách có chủ đích; công bố toàn bộ cụm lên internet để sửa một sự không khớp sẽ đổi một lỗi định tuyến lấy một sự phơi nhiễm không thể thu hồi.

Cũng giữ nguyên xác thực cơ sở dữ liệu và quyền theo vai trò của ứng dụng. Một địa chỉ VPN đã dịch dùng chung có thể đại diện cho nhiều người dùng hoặc dịch vụ, nên nó không bao giờ thay thế các danh tính cơ sở dữ liệu riêng biệt.

Mã hóa riêng máy khách-tới-nút và internode

Tài liệu bảo mật của Apache coi việc mã hóa máy khách-tới-nút và internode là các cấu hình riêng biệt, và bật cái này không bật cái kia. Sự khác biệt đó vẫn đúng bên trong VPN, vì đường hầm bảo vệ phân đoạn của chính nó và không tự động mở rộng từ tiến trình ứng dụng tới tiến trình cơ sở dữ liệu hay giữa mọi cặp thành viên cụm.

Một cấu hình bật cả hai một cách rõ ràng, thay vì thừa hưởng giá trị mặc định của mẫu, trông đại khái như sau:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

Trên các cấu hình máy chủ cho phép mã hóa máy khách tùy chọn, việc chấp nhận TLS có thể cùng tồn tại với việc chấp nhận các kết nối không mã hóa, nên hãy đọc chính sách hiệu lực chứ không phải ý định. Hãy lập kế hoạch tên chứng chỉ, phân phối tin cậy và gia hạn cho các điểm cuối mà mỗi máy khách thực sự liên hệ; thay tên máy chủ bằng địa chỉ IP thay đổi việc kiểm tra danh tính của máy khách, không chỉ tuyến đường của nó.

Giữ quản trị trên đường riêng của nó

Lưu lượng internode cần tập nút đồng cấp được phép và chính sách bảo vệ riêng. Truy cập quản trị, bao gồm JMX ở nơi nó được dùng, cần một nhóm người dùng riêng và xác thực riêng. Một ứng dụng được phép gửi truy vấn thông thường không vì thế mà cần mọi khả năng quản lý, và điều ngược lại còn tệ hơn: một đường quản trị lộ ra cho phân đoạn ứng dụng là tuyến ngắn nhất từ một lỗi đến một lần xây lại. Hãy viết hai nhóm đó riêng ra và nêu tên chủ sở hữu của chúng, vì thường đó là các nhóm khác nhau mà quy tắc đã bị gộp nhầm.

Giữ các quy tắc đám mây hiệu lực, quy tắc máy chủ và cấu hình trình lắng nghe thẳng hàng. Một trình lắng nghe riêng vẫn có thể bị lộ qua một bản dịch hoặc proxy ngoài ý muốn, và một quy tắc công khai rộng có thể nằm yên cạnh một quy tắc VPN hẹp cho đến khi ai đó kiểm toán cả hai cùng lúc.

Ở nơi người vận hành thực sự cần một đường quản lý, hãy giao cho nó một chủ sở hữu được nêu tên và thời hạn thông tin xác thực ngắn hơn của ứng dụng. Điều đó giữ việc ủy quyền hiển thị khi người tiếp theo thừa kế cụm.

Thiết kế hứa gì

Kiểm chứng cả ba lời hứa bằng các vai trò thật thay vì chỉ bằng kiểm thử kết nối. Một ứng dụng đã được phê duyệt phải hoàn thành công việc được phép và không gì hơn, một nguồn bị loại phải thất bại ở lối vào máy khách, và một danh tính ứng dụng phải bị từ chối trên các đường quản trị dành riêng. Hãy thêm việc kết nối lại của máy khách và chọn nút vào cùng bài kiểm thử triển khai, vì đó là nơi các lỗi khám phá xuất hiện.

Kết thúc bằng ba câu trong tài liệu thiết kế: máy khách nào có thể truy vấn, nút nào có thể giao tiếp và người vận hành nào có thể quản trị. Ở sau một VPN là thông tin cấu trúc mạng hữu ích, nhưng nó không phải câu trả lời cho bất kỳ câu hỏi nào trong ba câu đó.