힘내 커밋 감사


16

ssh를 통해 실행되는 git 서버가 있고 각 사용자는 시스템에서 unix 계정을 가지고 있습니다.

두 명의 사용자가 저장소에 액세스 할 수 있다고 가정하면 커밋 사용자 이름과 이메일이 git 클라이언트에 의해 제출되고 제어되므로 어떤 커밋을 수행했는지 어떻게 알 수 있습니까?

사용자가 동일한 권한을 가지고 있어도 다른 사람을 가장하려고 시도 할 수 있습니다.


혼란 스러워요. 각 사용자는 자신의 셸 계정을 가지고 있다는 질문에 의견을 말하지만 모두 단일 계정을 공유하고 인증을 위해 별도의 키를 사용한다고 말합니다. 어느 쪽입니까, 아니면 둘 다입니까?
Scott Pack

둘 중 하나 일 수 있습니다. 현재 설정은 질문에 설명 된 설정 (사용자 당 하나의 ssh 계정)이지만 확장 성이 떨어 지므로 앞으로 단일 사용자 / 많은 키로 가고 싶습니다. 하나 또는 다른 인증 방법으로 나를 잠그지 않는 가장 다양한 솔루션을 찾고 있습니다.
yannisf

1
"커밋을하는 사람"과 "이 레포로 커밋을 한 사람"은 일반적인 경우에 반드시 같은 것은 아니라는 점을 지적 할 가치가 있습니다. 귀하의 커밋을 귀하의 리포지토리에서 가져 와서 (나처럼) 타사 리포지토리로 푸시 할 수 있습니다.
nickgrim

답변:


13

걱정이되는 경우 몇 가지 방법으로 문제를 해결할 수 있습니다.

  1. 사용자가 커밋에 서명하면 GPG 서명이 지원됩니다.
  2. 사용자에게 기본 리포지토리에 커밋 할 권한을 부여하지 말고 자신의 하위 리포지토리에 커밋 한 다음 신뢰할 수있는 사용자가 변경 사항을 기본 리포지토리로 가져 오도록하십시오. git 프로젝트와 같은 일부 git 프로젝트의 로그 메시지를 보면 변경 사항을 만든 사람인 "Author"에 대한 별도의 필드임을 알 수 있습니다. "Committer"-저장소에 변경 사항을 커밋 한 사람.

1.이 제안은 제 목적에 가장 적합한 것 같습니다. 여전히 서버 측에서 서명되지 않은 커밋을 거부하는 메커니즘이 있습니까? 2.이 솔루션과 관련하여 하위 리포지토리에서 가져 오는 사용자는 커미터가 위조 된 사용자 이름 / 이메일을 사용하지 않았는지 다시 확인해야합니다. 진실?
yannisf

그러나 커미터 및 작성자 ID를 사용하여 커밋에 서명 할 수 있습니다. 분명히, 누가 단조를했는지 (또는 개인 키를 보지 않았는지) 볼 수 있습니다.
CB Bailey

따라서 신뢰할 수있는 사용자 만 주 저장소에 커밋하는 것에 대한주의 사항입니다.
Abizern

@Abizern : 충분합니다. 내가 읽었을 때, 당신의 (1)과 (2)는 대안적인 옵션을 설명하는 것으로 보았습니다.
CB Bailey

1
@yannisf 첫 번째 질문과 관련하여 업데이트 후크 (서버 측에서 실행)는 서명을 확인하고 그렇지 않으면 해당 참조 업데이트를 거부 할 수 있습니다. 상기 봐 가지고 .git/hooks/update.sample영감을. SO에서 이것에 대해 질문을하면 @ 저에게 알려주십시오. 나에게도 흥미로울 것입니다
Tobias Kienzler

9

이런 종류의 정보를 얻는 두 가지 좋은 방법이 있습니다. 하나는 sshd 자체에서 로깅을 늘리는 것이고 다른 하나는 디스크의 git 저장소에 대한 심층 모니터링을 수행하는 것입니다. 어느 쪽도 개별적으로 원하는 정보를 제공하지 않기 때문에 외부 로그 분석 엔진을 사용하거나 필요할 때 사람의 눈과 타임 스탬프를 사용하여 로그 데이터를 상관시키고 상관시킬 수 있습니다.

sshd 수정

의심 할 여지없이 기본적으로 ssh 인증 로그를 사용하여 언제 어디서 로그인했는지 확인할 수 있습니다. 당신이하고 싶은 것은 sshd에서 로그 아웃 할 때 레벨을 변경하는 것입니다. 그래서 당신을 편집 /etc/ssh/sshd_config하고 다음과 같은 줄을 찾으십시오.

#LogLevel INFO

그리고 그것을

LogLevel VERBOSE

그런 다음 sshd 서비스를 다시 시작하십시오. 이렇게하면 sshd의 로깅 수준이 1 단계 증가하여 더 많은 정보가 제공됩니다. 변경 한 후 원격 액세스에 대한이 로그 스 니펫을 확인하십시오.

Nov  2 08:37:09 node1 sshd[4859]: Connection from 10.10.10.5 port 50445
Nov  2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov  2 08:37:10 node1 sshd[4860]: Postponed publickey for scott from 10.10.10.5 port 50445 ssh2
Nov  2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov  2 08:37:10 node1 sshd[4859]: Accepted publickey for scott from 10.10.10.5 port 50445 ssh2
Nov  2 08:37:10 node1 sshd[4859]: pam_unix(sshd:session): session opened for user scott by (uid=0)
Nov  2 08:37:10 node1 sshd[4859]: User child is on pid 4862
Nov  2 08:40:27 node1 sshd[4862]: Connection closed by 10.10.10.5
Nov  2 08:40:27 node1 sshd[4862]: Transferred: sent 30632, received 7024 bytes
Nov  2 08:40:27 node1 sshd[4862]: Closing connection to 10.10.10.5 port 50445
Nov  2 08:40:27 node1 sshd[4859]: pam_unix(sshd:session): session closed for user scott 

여기서 주목해야 할 것은 두 가지입니다.

  1. 인증에 사용 된 공개 키의 지문이 보입니다.
  2. 로그 오프 타임 스탬프를 본다

기본 LogLevel (INFO) sshd를 사용하면 해당 항목이 모두 기록되지 않습니다. 키 지문을 얻는 것은 추가 단계입니다. authorized_keysssh-keygen을 사용 하여 적절한 파일 을 처리해야합니다 .

[root@node1 ssh]# ssh-keygen -l -f /home/scott/.ssh/authorized_keys
4096 f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06 /home/scott/.ssh/authorized_keys (RSA)

이제 다음 정보를 알게되었습니다.

  1. 로그온 한 사용자 이름
  2. 사용자가 로그온 한 시간
  3. 인증에 사용 된 공개 키
  4. 사용자가 로그 오프 한 시간

두 사용자가 동시에 로그인하지 않았다고 가정하면 특정 시간에 사용자 조치를 표시 할 수있는 방법이 생겼으므로 저장소의 변경 사항을 살펴볼 수 있습니다.

감사를 통한 디렉토리 모니터링

sysadmin1138이 말했듯이, 이것은 감사 된 하위 시스템의 훌륭한 사용 사례가 될 수 있습니다. RedHat 기반 배포판을 사용하지 않는 경우 아날로그가있을 수 있지만 찾아야합니다. 감사를위한 구성은 매우 강렬하며 수많은 구성 옵션이 있습니다. 몇 가지 옵션에 대한 아이디어를 얻으려면 자매 사이트에서 정보 보안 전문가를위한질문 을 확인하십시오 .

최소한 git 저장소가 포함 된 디스크의 디렉토리에 "watch"라는 것을 설정하는 것이 좋습니다. 이것이하는 일은 같은 파일 액세스 호출을 수행하려는 시도에 대한 보고서 커널 모듈 지시이다 open()또는 creat()파일이나 우리 목록 디렉토리를 가리키는 파일 핸들에.

이 작업을 수행하는 샘플 구성은 다음과 같습니다. 따라서 /etc/audit/audit.rules변경 사항을 적절하게 통합하려면 기존 내용을 읽고 이해해야합니다 .

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024

-w /path/to/git/repos-p wa

# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2

자세한 답변 주셔서 감사합니다! 실제로 시스템 관리자의 관점에서 완성되었습니다. 내가 찾고있는 것은 너무 낮은 수준의 감사로 해결할 필요가없는 솔루션이며, 사실 이후에 법의학을 해결하기보다는 위조 된 커밋을 방지하는 것이 이상적입니다.
yannisf

2
글쎄, 당신은 시스템 관리 사이트에 요청했고 나는 법의학 검사관입니다 .... :)
스콧 팩

5

취할 수있는 유일한 기술적 접근 방식은 ssh 연결의 ID를 신뢰하는 것입니다. 그런 다음 각 새로운 푸시 커밋의 커미터를 검증하여 각 사용자가 커밋을 푸시하도록 강제 할 수 있습니다.

이것이 신뢰성을 갖기 위해서는 거의 확실하게 사용자에게 저장소가있는 상자에 무제한 쉘 액세스를 제공하고 싶지는 않습니다. git-shell그렇지 않으면 제한 사항을 쉽게 해결할 수 있는 것과 같은 것을 사용해야 합니다.

그래도 사용자는 여전히 저자로 서로를 가장 할 수 있습니다. 이것을 제한 할 수도 있지만 체리 피킹 및 rebasing 및 아마도 분기 (훅 구현에 따라 다름)와 같은 일반적인 워크 플로우가 손실되므로이를 원하지 않을 수 있습니다.

어느 시점에서 어느 정도 개발자를 신뢰해야합니다.


3

많은 ssh 데몬 /var/log/audit.log은 ssh 연결이 수신 될 때 이와 비슷한 항목을 만듭니다 . 이 로그를 commit-log와 상호 참조하면 커밋을 실행하는 데 어떤 ssh-user가 사용되었는지 알 수 있습니다. 이는 검증 단계 이후에 사용되는 감사 단계입니다.

실제로 올바른 ssh-user를 적절한 git-user에게 적용하는 것은 여기에있는 다른 대답 중 하나입니다.


사용자가 동일한 ssh 사용자로 로그인하지만 다른 (권한) 키를 사용하는 설정이 여전히 있습니다. 이것은 감사를 더욱 어렵게 만듭니다.
yannisf

@ yannisf : 당신이 맞아요, 그것은 약간 변경됩니다. 운이 좋으면 귀속 할 수없는 계정 액세스를 처리해야하는 추가 요구 사항을 해결하는 데 도움이되었습니다.
Scott Pack

0

모든 사용자에게 리포지토리에 대한 쓰기 액세스 권한이있는 셸 계정이있는 경우 신뢰할 수있는 감사 로그를 설정할 수 없습니다. 로그에 쓰지 않고도 리포지토리를 수정할 수 있으며 원하는 모든 것을 로그에 쓸 수 있습니다.

감사 로그를 신뢰할 수 있으려면 리포지토리에 대한 액세스를 중재하기 위해 gitolite (자체 계정으로 실행)와 같은 것을 사용하는 대신 리포지토리에 대한 파일 수준의 직접 쓰기 액세스를 방지해야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.