Thực tiễn tốt nhất để quản lý khóa SSH trong một nhóm là gì?


42

Tôi làm việc với các nhóm nhỏ (<10) nhà phát triển và quản trị viên với các đặc điểm sau:

  • Hầu hết các thành viên của nhóm có> 1 máy tính cá nhân, hầu hết là máy tính xách tay
  • Các thành viên trong nhóm có quyền truy cập vào 10-50 máy chủ, thường là với sudo

Tôi nghĩ rằng điều này là khá điển hình cho hầu hết các công ty mới thành lập và các nhóm CNTT doanh nghiệp vừa và nhỏ.

Các thực tiễn tốt nhất để quản lý khóa SSH trong một nhóm như thế này là gì?

Bạn có nên chia sẻ một chìa khóa duy nhất cho cả nhóm?

Mỗi người nên có khóa riêng trên một tài khoản dùng chung ("ubfox" trên mọi máy chủ)?

Tài khoản riêng?

Mỗi thành viên trong nhóm nên giữ một khóa riêng cho mỗi máy tính xách tay hoặc máy tính để bàn của họ?

Câu trả lời:


33

Tại công ty của tôi, chúng tôi sử dụng LDAP để có một bộ tài khoản nhất quán trên tất cả các máy và sau đó sử dụng công cụ quản lý cấu hình (trong trường hợp của chúng tôi hiện là cengine) để phân phối authorized_keystệp cho mỗi người dùng trên tất cả các máy chủ. Các tệp chính được lưu giữ (cùng với thông tin cấu hình hệ thống khác) trong kho git để chúng ta có thể thấy khi nào khóa đến và đi. cfengine cũng phân phối một sudoerstệp kiểm soát những người có quyền truy cập để chạy những gì là root trên mỗi máy chủ, sử dụng người dùng và các nhóm từ thư mục LDAP.

Xác thực mật khẩu bị vô hiệu hóa hoàn toàn trên các máy chủ sản xuất của chúng tôi, vì vậy, xác thực khóa SSH là bắt buộc. Chính sách khuyến khích sử dụng một khóa riêng cho mỗi máy tính xách tay / máy tính để bàn / bất cứ điều gì và sử dụng cụm mật khẩu trên tất cả các phím để giảm tác động của máy tính xách tay bị mất / bị đánh cắp.

Chúng tôi cũng có một máy chủ pháo đài được sử dụng để truy cập các máy chủ trên mạng sản xuất, cho phép chúng tôi có các quy tắc tường lửa rất hạn chế xung quanh mạng đó. Hầu hết các kỹ sư có một số cấu hình SSH đặc biệt để làm cho điều này minh bạch:

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"

Thêm một khóa mới hoặc loại bỏ một khóa cũ đòi hỏi một chút nghi lễ trong thiết lập này. Tôi lập luận rằng để thêm một khóa mới, nó mong muốn nó là một hoạt động để lại dấu vết kiểm toán và mọi người đều có thể nhìn thấy. Tuy nhiên, do liên quan đến chi phí, tôi nghĩ mọi người đôi khi bỏ bê việc xóa chìa khóa cũ khi không còn cần thiết và chúng tôi không có cách nào thực sự để theo dõi điều đó ngoại trừ việc dọn dẹp khi một nhân viên rời khỏi công ty. Nó cũng tạo ra một số ma sát bổ sung khi đưa lên một kỹ sư mới, vì họ cần tạo ra một khóa mới và đẩy nó ra tất cả các máy chủ trước khi chúng có thể hoạt động hoàn toàn.

Tuy nhiên, lợi ích lớn nhất là có một tên người dùng riêng cho mỗi người dùng, giúp dễ dàng thực hiện kiểm soát truy cập chi tiết hơn khi chúng tôi cần và cung cấp cho mỗi người dùng một danh tính hiển thị trong nhật ký kiểm toán, có thể thực sự hữu ích khi cố gắng theo dõi vấn đề sản xuất trở lại một hành động sysadmin.

Thật khó chịu trong thiết lập này khi có các hệ thống tự động thực hiện hành động chống lại các máy chủ sản xuất, vì các khóa SSH "nổi tiếng" của chúng có thể phục vụ như một đường dẫn truy cập thay thế. Cho đến nay, chúng ta mới tạo tài khoản người dùng cho các hệ thống tự động này chỉ có quyền truy cập tối thiểu mà họ cần để thực hiện công việc của mình và chấp nhận rằng người dùng độc hại (phải là kỹ sư có quyền truy cập sản xuất) cũng có thể thực hiện các hành động tương tự như vậy. ẩn danh sử dụng khóa của ứng dụng.


Đây là một câu trả lời thực sự tốt! Câu hỏi tiếp theo: bạn sử dụng cfengine để phân phối. Trái phép. Bạn đã xem xét bất kỳ cách nào để lưu trữ khóa công khai SSH trong máy chủ LDAP của mình chưa? Họ chủ yếu yêu cầu vá sshd, mà cảm thấy mong manh.
Evan Prodromou

Tôi đã làm một cái gì đó tương tự với Chef.
gWaldo

1
@EvanProdromou Tôi đã thiết lập các khóa công khai SSH trong LDAP, nhưng nó rắc rối hơn nhiều so với giá trị của nó, do tôi phải tự cập nhật các gói SSH và đó là khoảng thời gian có một vài lỗ hổng SSH
Daniel Lawson

1
Quy tắc Sudo và khóa SSH cũng có thể được đặt trong LDAP, SSSD có thể được sử dụng để thiết lập điều này. Liên kết: sudo.ws/sudoers.ldap.man.htmlaccess.redhat.com/ledgeledge/docs/en-US/Red_Hat_ Entryprise_Linux / Lỗi
fuero

Tôi thích ProxyCommand ssh -qbit của bạn ở đó! Chưa bao giờ thấy điều đó. Tôi ngần ngại đưa lên một máy chủ pháo đài nhưng nếu nó có thể minh bạch cho người dùng cuối thì tôi có thể là tất cả cho nó. Cảm ơn Martin!
the0ther

6

Cá nhân tôi thích ý tưởng của mỗi thành viên trong đội ngũ nhân viên có một khóa trên máy pháo đài ssh chuyên dụng mà họ có tài khoản người dùng cơ bản. Tài khoản người dùng đó có khóa 1 ssh cấp quyền truy cập vào tất cả các máy chủ họ cần sử dụng. (những máy chủ khác này cũng nên được tắt tường lửa để chỉ truy cập ssh từ máy pháo đài được bật)

Sau đó, trên máy móc làm việc hàng ngày, máy tính xách tay, máy tính bảng, v.v. họ có thể tự lựa chọn có một phím giữa chúng hoặc nhiều phím.

Là quản trị viên hệ thống trên mạng đó, bạn có số lượng khóa tối thiểu để chăm sóc (mỗi khóa một lần), có thể dễ dàng theo dõi truy cập ssh qua mạng (vì tất cả các tuyến đều đi qua máy pháo đài) và nếu nhà phát triển muốn có nhiều khóa hoặc chỉ một máy họ chia sẻ giữa các máy của họ, đó không phải là vấn đề thực sự vì bạn chỉ có một máy để cập nhật. (trừ khi các khóa ssh của pháo đài bị xâm phạm, ut tbh khó xảy ra hơn một trong các khóa người dùng)


5

Tôi đã gặp tình huống cần cung cấp quyền truy cập khóa SSH cho một nhóm gồm 40 nhà phát triển cho ~ 120 máy chủ khách hàng từ xa.

Tôi đã kiểm soát truy cập bằng cách buộc các nhà phát triển kết nối thông qua một "máy chủ nhảy" duy nhất. Từ máy chủ đó, tôi đã tạo khóa riêng / công khai và đẩy chúng ra máy chủ của khách hàng. Nếu các nhà phát triển cần truy cập từ máy tính xách tay, họ có thể sử dụng cùng một khóa trên hệ thống cục bộ của họ.


2

Cá nhân tôi sẽ đi với mỗi người dùng sau đó bạn ngay lập tức có trách nhiệm và đặt ra các hạn chế dễ dàng hơn nhiều - tôi không biết người khác nghĩ gì?


2

Một cách tiếp cận tôi đã nghe nói, nhưng bản thân tôi không sử dụng, là cho mỗi người dùng có một gói (ví dụ: .deb, .rpm) có chứa cấu hình khóa công khai ssh của họ, cũng như bất kỳ dấu chấm nào họ muốn tùy chỉnh (.bashrc , .profile, .vimrc, v.v.). Điều này được ký và lưu trữ trong một kho lưu trữ của công ty. Gói này cũng có thể chịu trách nhiệm tạo tài khoản người dùng hoặc có thể bổ sung một thứ khác tạo tài khoản (cfengine / con rối, v.v.) hoặc hệ thống xác thực trung tâm như LDAP.

Các gói này sau đó được cài đặt vào máy chủ thông qua bất kỳ cơ chế nào bạn thích (cfengine / con rối, v.v., công việc cron). Một cách tiếp cận là có một siêu dữ liệu có sự phụ thuộc vào các gói cho mỗi người dùng.

Nếu bạn muốn xóa khóa chung, nhưng không phải người dùng, thì gói cho mỗi người dùng được cập nhật. Nếu bạn muốn xóa người dùng, bạn xóa gói.

Nếu bạn có các hệ thống không đồng nhất và phải duy trì cả hai tệp .rpm và .deb, thì tôi có thể thấy điều này hơi khó chịu, mặc dù các công cụ như người ngoài hành tinh có thể giúp việc đó dễ dàng hơn.

Như tôi nói, tôi đã không làm điều này bản thân mình. Lợi ích trong cách tiếp cận này với tôi là nó bổ sung cho hệ thống LDAP trung tâm và quản lý trung tâm tài khoản người dùng, trong đó cho phép người dùng dễ dàng cập nhật gói của mình để bao gồm tệp .vimrc của mình mà không cần phải quản lý tệp đó bởi các công cụ như con rối mà người dùng có thể không có quyền truy cập.


1

Bạn nên đi theo con đường an toàn hơn và buộc mỗi người dùng phải có các khóa riêng biệt và có thể cho từng thiết bị.

Nếu bạn có các khóa được chia sẻ giữa những người dùng --- ngay cả khi bạn là một nhóm nhỏ --- thu hồi khóa là một sự bất tiện cho những người khác.

Nếu bạn cho phép nhân viên của mình có một khóa cho tất cả các thiết bị của họ, thì họ có thể chọn và chọn máy chủ nào họ có thể kết nối với thiết bị đó. Ví dụ, một máy tính xách tay di động có thể bị hạn chế ở một hoặc hai máy chủ, nhưng máy tính để bàn tại văn phòng có thể có quyền truy cập vào tất cả các máy chủ.


1

Một vài năm trước, Envy Labs đã viết một công cụ có tên Keymaster (hợp tác với Gatekeeper của khách hàng) để xử lý một cái gì đó như thế này cho các nhóm phát triển.

Dự án đã không có nhiều tình yêu trong hai năm qua, nhưng nó có thể là thứ gì đó bạn có thể tin tưởng, và có lẽ mang lại cho cuộc sống?

Repo có sẵn trong github: https://github.com/envylabs/keymaster


-4

Một aproach có thể đang thiết lập máy chủ NIS với / chia sẻ nhà trên NFS. Điều đó kết hợp với sudo trong các máy chủ và chỉ cho phép người dùng bạn muốn đến từng máy chủ thông qua cấu hình ssh.

Bằng cách đó, mọi thành viên của nhóm chỉ sử dụng một người dùng và khóa của nó để truy cập tất cả các máy chủ. Sudo và một mật khẩu cho các nhiệm vụ quản trị viên.

Trân trọng,

Rafael


1
1) Kích hoạt NIS là một lỗ hổng bảo mật. 2) Có một mật khẩu và tài khoản trái với khả năng truy nguyên và trách nhiệm.
Deer Hunter
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.