Cổng truy cập SSH cho nhiều máy chủ


12

Quản lý nhiều máy chủ, vượt quá 90 hiện tại với 3 devops thông qua Ansible. Tất cả đang hoạt động rất tốt, tuy nhiên có một vấn đề bảo mật khổng lồ ngay bây giờ. Mỗi devop đang sử dụng khóa ssh cục bộ của riêng họ để có quyền truy cập trực tiếp vào máy chủ. Mỗi devop sử dụng một máy tính xách tay và mỗi máy tính xách tay có khả năng có thể bị xâm phạm, do đó mở toàn bộ mạng máy chủ prod cho đến một cuộc tấn công.

Tôi đang tìm kiếm một giải pháp để quản lý truy cập tập trung và do đó chặn truy cập cho bất kỳ khóa nào. Không giống với cách các phím được thêm vào bitbucket hoặc github.

Ngoài đỉnh đầu tôi sẽ cho rằng giải pháp sẽ là một đường hầm từ một máy, cổng, đến máy chủ prod mong muốn ... trong khi chuyển qua cổng, yêu cầu sẽ lấy một khóa mới và sử dụng để có quyền truy cập vào prod người phục vụ. Kết quả là chúng ta có thể tiêu diệt nhanh chóng và hiệu quả quyền truy cập cho bất kỳ tín đồ nào trong vòng vài giây bằng cách từ chối truy cập vào cổng.

nhập mô tả hình ảnh ở đây

Đây có phải là logic tốt? Có ai nhìn thấy một giải pháp ngoài kia đã để giải quyết vấn đề này?


1
Đã đến lúc chuyển sang AWX / Tower.
Michael Hampton

Gần đây tôi đã thử dùng Kryptonite để quản lý khóa SSH và 2FA và nó hoạt động khá tốt đối với tôi. gói pro / Enterprise của họ dường như còn kiểm soát nhiều hơn và kiểm tra thông tin đăng nhập ..
Alex

2
Câu trả lời là freeIPA
Jacob Evans

Câu trả lời:


22

Điều đó quá phức tạp (kiểm tra xem một khóa có quyền truy cập vào một máy chủ prod cụ thể không). Sử dụng máy chủ cổng làm máy chủ nhảy chấp nhận mọi khóa hợp lệ (nhưng có thể dễ dàng xóa quyền truy cập cho một khóa cụ thể, lần lượt loại bỏ quyền truy cập vào tất cả các máy chủ) và sau đó chỉ thêm các khóa được phép vào mỗi máy chủ tương ứng. Sau đó, đảm bảo bạn có thể truy cập cổng SSH của mọi máy chủ chỉ thông qua máy chủ nhảy.

Đây là cách tiếp cận tiêu chuẩn.


2
Thậm chí tốt hơn: làm những gì @Sven nói nhưng cũng thêm 2FA vào máy chủ nhảy. Bởi vì bạn chỉ kết nối trực tiếp từ máy tính xách tay khi bạn cần thủ công, phải không? Bất cứ điều gì tự động đang chạy từ một máy chủ bên trong máy chủ nhảy?
Adam

1
Nếu bạn có cơ quan chứng nhận cục bộ (cấp dưới hoặc bị cô lập), bạn có thể sử dụng các chứng chỉ đó với SSH, cho phép bạn vô hiệu hóa tập trung một chứng chỉ bị xâm phạm được tin tưởng.
Randall

11

Các kỹ sư không nên chạy trực tiếp từ máy tính xách tay của họ, trừ khi đây là môi trường dev / test.

Thay vào đó, có một máy chủ trung tâm kéo các cuốn sách từ git. Điều này cho phép kiểm soát bổ sung (bốn mắt, xem lại mã).

Kết hợp điều này với một pháo đài hoặc máy chủ nhảy để hạn chế quyền truy cập hơn nữa.


1
Thật vậy, đây là vấn đề mà AWX (hoặc Tháp phiên bản thương mại của nó) giải quyết.
Michael Hampton

1

Netflix đã triển khai thiết lập của bạn và phát hành một số phần mềm miễn phí để giúp giải quyết tình huống đó.

Xem video này https://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-access hoặc bản trình bày này tại https://speakerdeck.com/rlewis/how-netflix-gives- all-it-tests-ssh-access-to-instance-running-in-sản xuất với điểm cốt lõi:

Chúng tôi sẽ xem xét kiến ​​trúc pháo đài SSH của chúng tôi, trong đó cốt lõi sử dụng SSO để xác thực các kỹ sư và sau đó phát hành thông tin xác thực cho mỗi người dùng với các chứng chỉ tồn tại ngắn để xác thực SSH của pháo đài thành một thể hiện. Những thông tin ngắn hạn làm giảm rủi ro liên quan đến việc họ bị mất. Chúng tôi sẽ đề cập đến cách tiếp cận này cho phép chúng tôi kiểm toán và tự động cảnh báo sau thực tế, thay vì làm chậm các kỹ sư trước khi cấp quyền truy cập.

Phần mềm của họ có sẵn tại đây: https://github.com/Netflix/bless

Một số cách thú vị ngay cả khi bạn không thực hiện toàn bộ giải pháp của họ:

  • họ sử dụng chứng chỉ SSH thay vì chỉ các khóa; bạn có thể đặt nhiều dữ liệu meta hơn trong chứng chỉ, do đó cho phép nhiều ràng buộc cho mỗi yêu cầu và cũng cho phép kiểm toán đơn giản hơn
  • sử dụng hiệu lực của chứng chỉ rất ngắn hạn (như 5 phút) (các phiên SSH vẫn mở ngay cả khi hết hạn chứng chỉ)
  • sử dụng 2FA để gây khó khăn cho kịch bản và buộc các nhà phát triển phải tìm giải pháp khác
  • một mô hình con cụ thể, bên ngoài cơ sở hạ tầng của họ và được bảo mật đúng cách thông qua các cơ chế bảo mật được cung cấp bởi đám mây nơi nó chạy, xử lý việc tạo chứng chỉ một cách linh hoạt để mỗi nhà phát triển có thể truy cập vào bất kỳ máy chủ nào

1

SPS OneIdentity (ex-Balabit) là điều chính xác bạn cần trong kịch bản này. Với thiết bị này, bạn có thể quản lý danh tính người dùng trên cơ bản bất kỳ máy nào, theo dõi hành vi của người dùng, theo dõi và cảnh báo và lập chỉ mục bất cứ điều gì người dùng làm cho các đánh giá sau này.


0

Đề nghị của tôi là không cho phép truy cập SSH từ máy người dùng.

Thay vào đó bạn nên

  1. Lưu trữ các vở kịch trong Git.
  2. Biến "Máy chủ truy cập" thành máy chủ Jenkins.
  3. Cấp chỉ cần Jenkins truy cập để người dùng sùng đạo.
  4. Thực thi Ansible chơi trên Jenkins qua xây dựng công việc thông qua HTTP.
  5. Là một biện pháp bảo mật bổ sung, vô hiệu hóa Jenkins CLI nếu cần.

Mô hình thực hiện mẫu,

  1. Plugin Ansible của Jenkins: https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

HOẶC LÀ

  1. Vỏ cổ điển - loại công việc hiện tại. Thêm các bước xây dựng của bạn bằng tay, bao gồm kiểm tra git.

Nếu bạn bị giới hạn tài nguyên máy chủ, cùng một máy chủ Jenkins cũng có thể lưu trữ Git (scm-manager), mặc dù có một rủi ro bảo mật bổ sung nếu một trong các máy của nhà phát triển bị nhiễm. Bạn có thể giảm thiểu điều này bằng cách ngắt kết nối máy chủ Jenkins khỏi internet và giải quyết các phụ thuộc Ansible cục bộ.

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.