다음과 같은 특징을 가진 소규모 팀 (<10)의 개발자 및 관리자와 협력합니다.
- 대부분의 팀원은 개인용 컴퓨터가 1 개 이상이며, 대부분 휴대용
- 팀원은 일반적으로 sudo를 사용하여 10-50 대의 서버에 액세스 할 수 있습니다.
나는 이것이 대부분의 신생 기업과 중소 기업 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 키가 대체 액세스 경로로 사용될 수 있기 때문에 프로덕션 호스트에 대해 조치를 취하는 자동화 된 시스템을 갖는 것은이 설정에서 귀찮습니다. 지금까지 우리는 자동화 시스템에 대한 사용자 계정이 작업을 수행하는 데 필요한 최소한의 액세스 권한 만 갖도록 만들었으며 악의적 인 사용자 (이미 프로덕션 액세스 권한을 가진 엔지니어 여야 함)도 이와 동일한 작업을 수행 할 수 있음을 인정했습니다. 익명으로 응용 프로그램 키를 사용합니다.
답변
개인적으로 저는 직원마다 기본 사용자 계정이있는 전용 ssh 배스 천 머신에 하나의 키가 있다는 아이디어를 좋아합니다. 해당 사용자 계정에는 1 개의 ssh 키가 있으며 사용하는 모든 서버에 대한 액세스 권한을 부여합니다. (이러한 다른 서버들도 방화벽이 꺼져 있어야 요새 컴퓨터에서 ssh 액세스 만 가능합니다)
그런 다음 일상적인 작업 기계, 랩톱, 태블릿 등에서 하나의 키 또는 여러 키 사이에서 원하는 키를 선택할 수 있습니다.
해당 네트워크의 시스템 관리자는 볼 수있는 최소한의 키 수 (개발자 당 하나)를 가지고 있으며, 네트워크를 통한 ssh 액세스를 쉽게 모니터링 할 수 있습니다 (모든 포트 션 머신을 통해 라우팅 됨). 컴퓨터간에 공유하는 컴퓨터는 업데이트 할 컴퓨터가 하나뿐이므로 문제가되지 않습니다. (요새 ssh 키가 손상되지 않는 한 사용자 키 중 하나보다 훨씬 가능성이 낮은 tbh)
답변
40 명의 개발자 팀이 ~ 120 개의 원격 고객 서버에 SSH 키 액세스를 제공해야하는 상황이있었습니다.
개발자가 단일 “점프 호스트”를 통해 연결하도록하여 액세스를 제어했습니다. 그 호스트에서 개인 / 공개 키를 생성하여 고객 서버로 푸시했습니다. 개발자가 랩톱에서 액세스해야하는 경우 로컬 시스템에서 동일한 키 쌍을 사용할 수 있습니다.
답변
나는 개인적으로 사용자마다 가고 당신은 즉시 책임을 가지고 훨씬 더 쉽게 제한을 설정합니다-다른 사람들이 어떻게 생각하는지 모르겠어요?
답변
내가 들었지 만 나 자신이 사용하지 않은 한 가지 접근법은 각 사용자가 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
