다음과 같은 특징을 가진 소규모 팀 (<10)의 개발자 및 관리자와 협력합니다.
나는 이것이 대부분의 신생 기업과 중소 기업 IT 그룹에게 꽤 일반적이라고 생각합니다.
이와 같은 팀에서 SSH 키를 관리하는 모범 사례는 무엇입니까?
팀 전체에 대해 단일 키를 공유해야합니까?
각 사람이 공유 계정에 자신의 키를 가져야합니까 (모든 서버에서 "우분투")?
별도의 계정?
각 팀원이 랩톱 또는 데스크톱 컴퓨터마다 별도의 키를 보관해야합니까?
답변:
우리 회사에서는 LDAP를 사용하여 모든 머신에서 일관된 계정 세트를 보유한 다음 구성 관리 도구 (이 경우 현재 cfengine)를 authorized_keys사용하여 모든 서버에 각 사용자의 파일 을 분배 합니다. 키 파일 자체는 다른 시스템 구성 정보와 함께 git 저장소에 보관되므로 키가 언제 나오는지 확인할 수 있습니다. cfengine은 또한 sudoersLDAP 디렉토리의 사용자 및 그룹을 사용하여 각 호스트에서 루트로 무엇을 실행할 수있는 액세스 권한이 있는지를 제어 하는 파일을 배포합니다 .
프로덕션 서버에서는 비밀번호 인증이 완전히 비활성화되어 있으므로 SSH 키 인증은 필수입니다. 정책은 각 랩톱 / 데스크톱 / 무엇에 대해 별도의 키를 사용하고 모든 키에 암호를 사용하여 분실 / 도난 랩톱의 영향을 줄 이도록 권장합니다.
또한 프로덕션 네트워크의 호스트에 액세스하는 데 사용되는 요새 호스트도 있으므로 해당 네트워크에 대해 매우 제한적인 방화벽 규칙을 가질 수 있습니다. 대부분의 엔지니어는이를 투명하게하기 위해 특별한 SSH 구성을 가지고 있습니다.
Host prod-*.example.com
User jsmith
ForwardAgent yes
ProxyCommand ssh -q bastion.example.com "nc %h %p"새 키를 추가하거나 이전 키를 제거하면이 설정에서 약간의식이 필요합니다. 새 키를 추가하려면 감사 내역을 남기고 모든 사람이 볼 수있는 작업이 바람직하다고 주장합니다. 그러나 오버 헤드가 관련되어 있기 때문에 사람들은 때때로 더 이상 필요하지 않을 때 이전 키를 제거하는 것을 무시하고 직원이 회사를 떠날 때 정리하는 것 외에는 키를 추적 할 실제 방법이 없습니다. 또한 새 엔지니어를 온 보딩 할 때 새로운 키를 생성하고 모든 생산성을 발휘하기 전에 모든 호스트로 푸시해야하기 때문에 추가적인 마찰이 발생합니다.
그러나 가장 큰 이점은 각 사용자마다 별도의 사용자 이름을 사용하는 것이므로 필요할 때보다 세분화 된 액세스 제어를 쉽게 수행 할 수 있으며 각 사용자에게 감사 로그에 표시되는 ID를 제공하므로이 정보를 추적 할 때 매우 유용합니다. 생산 문제는 다시 sysadmin 작업으로 돌아갑니다.
"잘 알려진"SSH 키가 대체 액세스 경로로 사용될 수 있기 때문에 프로덕션 호스트에 대해 조치를 취하는 자동화 된 시스템을 갖는 것은이 설정에서 귀찮습니다. 지금까지 우리는 자동화 시스템에 대한 사용자 계정이 작업을 수행하는 데 필요한 최소한의 액세스 권한 만 갖도록 만들었으며 악의적 인 사용자 (이미 프로덕션 액세스 권한을 가진 엔지니어 여야 함)도 이와 동일한 작업을 수행 할 수 있음을 인정했습니다. 익명으로 응용 프로그램 키를 사용합니다.
ProxyCommand ssh -q비트를 좋아 한다! 본 적이 없습니다. 요새 서버를 설치하는 것이 주저하지만 최종 사용자에게 투명 할 수 있다면 모든 것이 될 수 있습니다. 고마워 마틴!
개인적으로 저는 직원마다 기본 사용자 계정이있는 전용 ssh 배스 천 머신에 하나의 키가 있다는 아이디어를 좋아합니다. 해당 사용자 계정에는 1 개의 ssh 키가 있으며 사용하는 모든 서버에 대한 액세스 권한을 부여합니다. (이러한 다른 서버들도 방화벽이 꺼져 있어야 요새 컴퓨터에서 ssh 액세스 만 가능합니다)
그런 다음 일상적인 작업 기계, 랩톱, 태블릿 등에서 하나의 키 또는 여러 키 사이에서 원하는 키를 선택할 수 있습니다.
해당 네트워크의 시스템 관리자는 볼 수있는 최소한의 키 수 (개발자 당 하나)를 가지고 있으며, 네트워크를 통한 ssh 액세스를 쉽게 모니터링 할 수 있습니다 (모든 포트 션 머신을 통해 라우팅 됨). 컴퓨터간에 공유하는 컴퓨터는 업데이트 할 컴퓨터가 하나뿐이므로 문제가되지 않습니다. (요새 ssh 키가 손상되지 않는 한 사용자 키 중 하나보다 훨씬 가능성이 낮은 tbh)
내가 들었지 만 나 자신이 사용하지 않은 한 가지 접근법은 각 사용자가 ssh 공개 키 구성을 포함하는 패키지 (예 : .deb, .rpm)와 사용자 정의하려는 도트 파일 (.bashrc)을 갖는 것입니다. , .profile, .vimrc 등). 이것은 서명되고 회사 저장소에 저장됩니다. 이 패키지는 사용자 계정 생성을 담당하거나 계정 생성 (cfengine / puppet 등) 또는 LDAP와 같은 중앙 인증 시스템을 보완 할 수도 있습니다.
그런 다음이 패키지는 원하는 메커니즘 (cfengine / puppet 등, cron 작업)을 통해 호스트에 설치됩니다. 한 가지 방법은 사용자 별 패키지에 종속되는 메타 패키지를 갖는 것입니다.
공개 키는 제거하지만 사용자는 제거하지 않으려면 사용자 별 패키지가 업데이트됩니다. 사용자를 제거하려면 패키지를 제거하십시오.
이기종 시스템을 가지고 있고 .rpm과 .deb 파일을 모두 유지해야하는 경우에는 외계인과 같은 도구가 다소 쉬울 수 있지만 약간 성가신 것을 알 수 있습니다.
내가 말했듯이, 나는 이것을 직접하지 않았습니다. 이 접근 방식의 이점은 사용자가 중앙 LDAP 시스템과 사용자 계정의 중앙 관리를 보완하여 사용자가 예를 들어 파일을 관리하지 않고도 자신의 .vimrc 파일을 포함하도록 패키지를 쉽게 업데이트 할 수 있다는 점입니다 꼭두각시와 같은 도구로 사용자가 액세스하지 못할 수도 있습니다.
몇 년 전 Envy Labs는 개발 팀을 위해 이와 같은 것을 처리하기 위해 Keymaster (클라이언트 Gatekeeper와 파트너 관계)라는 도구를 작성했습니다.
이 프로젝트는 지난 2 년 동안 많은 사랑을받지 못했지만, 아마도 당신이 생각할 수 있고 아마도 다시 살아날 수 있을까요?
저장소는 github에서 사용할 수 있습니다 : https://github.com/envylabs/keymaster