우리 회사에서는 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 키가 대체 액세스 경로로 사용될 수 있기 때문에 프로덕션 호스트에 대해 조치를 취하는 자동화 된 시스템을 갖는 것은이 설정에서 귀찮습니다. 지금까지 우리는 자동화 시스템에 대한 사용자 계정이 작업을 수행하는 데 필요한 최소한의 액세스 권한 만 갖도록 만들었으며 악의적 인 사용자 (이미 프로덕션 액세스 권한을 가진 엔지니어 여야 함)도 이와 동일한 작업을 수행 할 수 있음을 인정했습니다. 익명으로 응용 프로그램 키를 사용합니다.

답변