Bảo mật rối và cấu trúc liên kết mạng

Lý lịch:

Cuối cùng tôi cũng dành một chút thời gian để tham gia Thế kỷ 21 và nhìn vào Con rối.

Vì ngày nay, phiên bản của chúng tôi kiểm soát tất cả các cấu hình máy chủ trong một kho lưu trữ được tổ chức nội bộ tại văn phòng. Khi cần cập nhật, các thay đổi sẽ được kiểm tra lại trong repos và được đẩy thủ công ra máy. Điều này thường có nghĩa là SFTP đến máy từ xa và sau đó di chuyển các tệp vào vị trí, với các quyền có liên quan, từ một vỏ.

Vì vậy, tôi hy vọng rằng Puppet sẽ là một phần mở rộng đơn giản nhưng tuyệt vời cho những gì chúng ta đã có.

Bây giờ tôi xem xét quá trình mà chúng ta hiện phải bảo mật một cách hợp lý. Giả định rằng mạng nội bộ của chúng tôi sẽ luôn tương đối an toàn hơn các mạng công cộng trong trung tâm dữ liệu của chúng tôi.

• Quá trình luôn luôn là một cách. Thay đổi đi qua từ một môi trường an toàn đến không an toàn và không bao giờ ngược lại.

• Cửa hàng chính là nơi an toàn nhất có thể. Nguy cơ thỏa hiệp, bằng cách đánh cắp cấu hình hoặc gửi các sửa đổi độc hại, được giảm đáng kể.

Câu hỏi:

Từ những gì tôi hiểu về mô hình máy chủ / máy khách rối là các máy khách thăm dò ý kiến ​​và kéo cập nhật trực tiếp từ máy chủ. Lưu lượng được bọc SSL nên không thể bị chặn hoặc giả mạo. Nhưng nó khác với những gì chúng tôi hiện đang làm vì máy chủ rối sẽ cần được lưu trữ ở một địa điểm công cộng. Hoặc là tập trung, hoặc một cho mỗi trang web trung tâm mà chúng tôi duy trì.

Vì vậy, tôi tự hỏi:

• Tôi có bị hoang tưởng một cách không cần thiết về sự thay đổi từ đẩy sang kéo không?

• Tôi có bị hoang tưởng một cách không cần thiết về việc lưu trữ tập trung tất cả thông tin đó trên mạng công cộng không?

• Làm thế nào những người khác duy trì nhiều mạng - máy chủ riêng biệt cho mỗi trang web?

Cập nhật 30/07/09:

Tôi đoán rằng một trong những mối quan tâm lớn khác của tôi là đặt nên phải tin tưởng vào một máy duy nhất. (Các) con rối sẽ được tường lửa, bảo mật và như vậy. Nhưng ngay cả như vậy, bất kỳ máy công cộng nào có dịch vụ nghe đều có bề mặt tấn công ở một kích thước nhất định.

Có lẽ nếu chủ nhân có quyền cập nhật bất kỳ tệp nào trên bất kỳ máy khách rối nào, thì sự thỏa hiệp cuối cùng sẽ dẫn đến sự thỏa hiệp của tất cả các máy khách đó. "Các vị vua cho vương quốc" có thể nói như vậy.

• Liệu giả thuyết đó có đúng không?

• Có cách nào để giảm nhẹ?

Bởi vì đôi khi tôi lưu trữ mật khẩu trong các biến trong các mô-đun của mình, để có thể triển khai các ứng dụng mà không phải hoàn tất cấu hình thủ công, điều đó có nghĩa là tôi không thể đặt repo con rối của mình lên máy chủ công cộng. Làm như vậy có nghĩa là tấn công người điều khiển rối sẽ cho phép lấy một số mật khẩu ứng dụng hoặc db của tất cả các ứng dụng khác nhau trên tất cả các máy chủ của chúng tôi.

Vì vậy, con rối của tôi ở trong mạng riêng của văn phòng chúng tôi và tôi không chạy con rối da rối trên các máy chủ. Khi tôi cần triển khai, tôi sử dụng ssh từ mạng riêng đến máy chủ, tạo một đường hầm và gọi con rối từ xa.
Bí quyết không phải là thiết lập đường hầm từ xa và máy khách rối để kết nối với người điều khiển rối, mà là một proxy chấp nhận kết nối http và có thể truy cập máy chủ rối trong mạng riêng. Nếu không, con rối sẽ từ chối kéo vì xung đột tên máy chủ với chứng chỉ

# From a machine inside privatenet.net :
ssh -R 3128:httpconnectproxy.privatenet.net:3128 \
    -t remoteclient.publicnetwork.net \
    sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \
    --http_proxy_host localhost --http_proxy_port 3128 \
    --waitforcert 60 --test –-verbose

Nó làm việc cho tôi, hy vọng nó sẽ giúp bạn

Chúng tôi có hai trang web, văn phòng của chúng tôi và colo của chúng tôi. Mỗi trang web có con rối riêng. Chúng tôi thiết lập một kho lưu trữ svn với cấu trúc sau:

root/office
root/office/manifests/site.pp
root/office/modules
root/colo
root/colo/manifests/site.pp
root/colo/modules
root/modules

Thư mục mô-đun dưới mỗi trang web là thư mục svn: externals trở lại thư mục mô-đun cấp cao nhất. Điều này có nghĩa là họ chia sẻ chính xác cùng một thư mục mô-đun. Sau đó, chúng tôi đảm bảo rằng phần lớn các lớp chúng tôi viết nằm trong thư mục mô-đun và được cả hai trang web sử dụng. Điều này có lợi thế tốt là buộc chúng ta phải suy nghĩ rộng rãi và không ràng buộc một lớp học với một trang web cụ thể.

Về bảo mật, chúng tôi lưu trữ con rối của chúng tôi (và phần còn lại của mạng) đằng sau tường lửa của chúng tôi, vì vậy chúng tôi không quan tâm đến việc lưu trữ cấu hình tập trung. Con rối sẽ chỉ gửi cấu hình để lưu trữ nó tin tưởng. Rõ ràng bạn cần giữ an toàn cho máy chủ đó.

Tôi không thể đưa ra đánh giá về mức độ cần thiết của chứng hoang tưởng của bạn, nó phụ thuộc rất nhiều vào môi trường của bạn. Tuy nhiên, tôi có thể tự tin nói rằng hai điểm chính trong cấu hình hiện tại của bạn vẫn có thể áp dụng. Bạn có thể đảm bảo thay đổi của mình đi qua từ một môi trường an toàn (kho lưu trữ tại văn phòng của bạn) đến môi trường kém an toàn hơn, bất cứ nơi nào con rối của bạn được đặt. Bạn thay đổi quy trình từ SFTP'ing sang một loạt các máy chủ và đặt các tệp theo cách thủ công để đặt SFTP'ing cho con rối của bạn và để Puppet phân phối các tệp và đặt chúng vào đúng vị trí. Cửa hàng chính của bạn vẫn là kho lưu trữ và rủi ro của bạn được giảm thiểu.

Tôi không tin rằng đẩy hoặc kéo vốn đã an toàn hơn so với mô hình khác. Con rối thực hiện một công việc tuyệt vời là đảm bảo các cấu hình trong quá trình vận chuyển, cũng như xác thực cả máy khách và máy chủ để đảm bảo có sự tin tưởng hai chiều.

Đối với nhiều mạng - chúng tôi xử lý nó với một nghệ sĩ múa rối "chính" trung tâm với các nghệ sĩ múa rối sattelite tại mỗi địa điểm đóng vai trò là khách hàng của chủ trung tâm.

Một cách tiếp cận thiết kế là để một người điều khiển rối cục bộ đến từng vị trí của các hệ thống và sử dụng một công cụ triển khai để thúc đẩy các thay đổi cho người điều khiển rối. (Sử dụng git với móc git cũng có thể hoạt động).

Điều này sẽ duy trì mối quan tâm của bạn về các dịch vụ nghe trên mạng công cộng vì lưu lượng truy cập mạng con rối sẽ chỉ là nội bộ.

Cũng có thể đẩy các bảng kê khai ra từng máy chủ và để máy khách con rối phân tích các bảng kê khai và áp dụng các cấu hình có liên quan.

mặc dù bạn nói "bên ngoài", tôi thực sự nghi ngờ những người tùy tiện cần kết nối với người điều khiển rối của bạn. bạn luôn có thể ném VPN vào hỗn hợp. một người bạn của tôi đã từng hỏi tôi "bạn có cần lo lắng về tính bảo mật của giao thức nếu kết nối được bảo mật không?" trong khi tôi không đồng ý với thái độ đó, một lớp thêm không bao giờ bị tổn thương và chắc chắn có tác dụng kỳ diệu đối với chứng hoang tưởng cá nhân của tôi. Bên cạnh đó, niềm vui của nó để đường hầm đường hầm.

Mark Burgess, tác giả của cengine và một giáo sư đại học (con rối đó dường như nợ di sản của nó) đã viết rất nhiều về đẩy và kéo. Ông tuyên bố kéo vốn đã an toàn hơn. Nếu bạn xem trang web của cengine, họ chỉ có 1 sự cố an ninh mạng trong 17 năm. Burgess tuyên bố đó là do thiết kế kéo. Tôi nghĩ rằng một điểm thỏa hiệp là không thể tránh khỏi. Tôi sẽ quan tâm nhiều hơn về các tuyến tấn công đến thời điểm đó.

Bạn có thể chạy rối mà không cần một bậc thầy trung tâm nếu bạn muốn. Một phương pháp tôi đã thấy là sử dụng kho lưu trữ git và có các tập lệnh sẽ chỉ hợp nhất và triển khai bản cập nhật chỉ khi thẻ được ký bởi một trong danh sách các khóa gpg được cài đặt sẵn. Mọi người thậm chí đã tìm ra cách để có được các cấu hình được lưu trữ (được sử dụng để thiết lập giám sát nagios trên một máy chủ trung tâm từ một tài nguyên được xử lý trên một máy chủ khác).

Vì vậy, nếu máy chủ git trung tâm bị xâm nhập, các máy chủ khác sẽ không áp dụng thêm bất kỳ cập nhật nào từ nó. Các khóa gpg sẽ có trên máy tính xách tay quản trị hệ thống hoặc một cái gì đó, cùng với một số cách thu hồi các phím.

Đọc thêm tại http: // c Hiện. Workdirectory.net/posts/2011/puppet-without-masters/