GitHub Foundations #8 Domain 6: 프라이버시·보안·관리 — 권한·2FA·Dependabot
Domain 6은 GitHub Foundations에서 경계 구분 문제가 가장 많이 나오는 영역입니다. 저장소 role 다섯 단계 중 어디부터 설정을 바꿀 수 있는지, Dependabot의 세 기능이 각각 무엇을 하는지처럼, 비슷해 보이는 것들 사이의 정확한 경계를 묻습니다. 외울 것이 많아 보이지만 전부 “누가 무엇을 할 수 있는가"와 “어떤 위협을 어느 단계에서 막는가"라는 두 질문으로 정리됩니다.
저장소 권한 — collaborator와 role 5단계 #
개인 계정의 저장소는 소유자가 collaborator를 초대해 접근을 부여합니다. Organization의 저장소는 더 세분화된 role 5단계로 권한을 나눕니다. 이 표가 Domain 6의 최다 출제 지점입니다.
| Role | 할 수 있는 일 | 전형적인 대상 |
|---|---|---|
| Read | 코드 열람, 이슈·PR 코멘트 | 열람만 필요한 구성원 |
| Triage | Read + 이슈·PR 관리 (라벨, 할당, 닫기) | 코드 변경 없는 이슈 관리자 |
| Write | Triage + push, PR 머지, 릴리스 작성 | 일반 개발자 |
| Maintain | Write + 위험하지 않은 저장소 설정 관리 | 프로젝트 리드 |
| Admin | 모든 설정, 보안 기능, collaborator 관리, 삭제 | 저장소 관리자 |
경계를 묻는 문제의 판별 기준은 두 곳입니다. 코드를 push할 수 있는 첫 단계는 Write이고, 보안 설정과 저장소 삭제처럼 파급이 큰 작업은 Admin 전용입니다. Triage는 코드 접근 없이 이슈만 정리하는 역할, Maintain은 Admin에서 위험 작업을 뺀 역할로 기억하면 시나리오 문제에 대응할 수 있습니다.
Organization — owner·member·팀 #
Organization 수준의 권한은 두 층입니다.
- Organization role — owner는 조직 설정, 멤버 관리, 결제까지 모든 권한을 갖고, member는 조직에 속할 뿐 저장소 권한은 별도로 받습니다. 조직 밖 사람에게 특정 저장소만 열어 주는 outside collaborator도 구분 대상입니다.
- 팀(Team) — 저장소 권한을 사람 단위가 아니라 팀 단위로 부여하는 그릇입니다. 팀 아래 하위 팀을 두는 중첩 구조를 지원하고, 상위 팀의 권한이 하위 팀에 상속됩니다. PR 리뷰어로 팀을 지정하거나
@org/team-name으로 멘션할 수도 있습니다.
조직 전체의 base permission은 모든 멤버가 모든 저장소에 기본으로 갖는 권한(None〜Write)입니다. 최소 권한 원칙을 물으면 base permission을 낮게 두고 팀으로 필요한 만큼 부여하는 방향이 답입니다.
인증 — 2FA·PAT·SSH #
계정 보호와 API 접근 수단도 시험 범위입니다.
- 2FA(2단계 인증) — TOTP 인증 앱, 보안 키(WebAuthn), GitHub Mobile 승인, SMS를 지원합니다. GitHub는 활동 계정에 2FA를 의무화해 왔으므로 “권장 사항"이 아니라 “요구 사항"으로 기억합니다. passkey로 비밀번호 없이 로그인하는 방식도 지원됩니다.
- PAT(Personal Access Token) — 비밀번호 대신 쓰는 API·HTTPS 인증 토큰입니다. 두 종류의 구분이 출제 포인트입니다. classic은 계정 전체에 걸친 넓은 스코프를 갖고, fine-grained는 대상 저장소와 권한을 좁게 지정하며 만료일이 필수입니다. 최소 권한 관점의 답은 항상 fine-grained입니다.
- SSH 키 — HTTPS 대신 키 쌍으로 인증하는 통신 방식입니다. 공개키를 계정에 등록해 두면 clone·push에 비밀번호가 필요 없습니다.
branch protection과 rulesets #
공유 브랜치를 실수로부터 지키는 서버 측 장치입니다. main 같은 브랜치에 다음을 강제할 수 있습니다.
- PR 없이 직접 push 금지, 승인 리뷰 최소 인원
- 지정한 상태 체크(CI) 통과 전 머지 차단
- force push와 브랜치 삭제 차단
같은 목적을 더 넓은 범위(태그, 여러 브랜치 패턴, 조직 수준)에 적용하는 새 형식이 rulesets입니다. 시험 수준에서는 “브랜치를 보호하는 규칙 장치"라는 공통 목적과, rulesets가 더 새로운 통합 형식이라는 정도의 구분이면 충분합니다.
보안 기능 지도 — 무엇이 어떤 위협을 막는가 #
Domain 6에서 role 표 다음으로 자주 나오는 것이 보안 기능들의 경계입니다. 각 기능이 무엇을 감시 대상으로 삼는지로 구분합니다.
| 기능 | 감시 대상 | 하는 일 |
|---|---|---|
| Dependabot alerts | 의존성 | 알려진 취약점이 있는 의존성을 경고 |
| Dependabot security updates | 의존성 | 취약한 의존성을 고치는 PR을 자동 생성 |
| Dependabot version updates | 의존성 | 취약점과 무관하게 정기 업데이트 PR 생성 (dependabot.yml 설정) |
| Secret scanning | 커밋 내용 | 저장소에 들어온 토큰·키 패턴을 탐지해 경고 |
| Push protection | push 시점 | 비밀키가 포함된 push 자체를 수신 단계에서 차단 |
| Code scanning (CodeQL) | 소스 코드 | 코드 자체의 취약한 패턴(인젝션 등)을 분석 |
Dependabot 세 기능의 구분이 특히 단골입니다. alerts는 경고, security updates는 취약점 수정 PR, version updates는 정기 업데이트 PR입니다. secret scanning과 push protection은 사후 탐지와 사전 차단의 관계입니다. push protection이 실무에서 어떤 사고를 막아 주는지는 Git에 비밀키를 커밋했을 때 — 키 회전과 filter-repo 히스토리 정리에서 사고 대응 절차와 함께 정리했습니다.
의존성 현황 자체를 보여 주는 dependency graph, 보안 신고 창구를 안내하는 SECURITY.md, 취약점을 공표하고 패치 버전을 알리는 security advisory까지가 이 지도의 나머지 조각입니다.
audit log와 검증된 커밋 #
관리 영역에서 두 가지가 더 나옵니다.
- Audit log — Organization에서 누가 언제 무엇을 했는지(멤버 초대, 권한 변경, 저장소 삭제 등)를 기록한 이벤트 로그입니다. 조직의 owner가 보안 사고 조사나 규정 준수 확인에 사용합니다. 저장소 활동 통계를 보는 Insights와 혼동하지 않도록 구분해 둡니다.
- 커밋 서명(verified) — GPG나 SSH 키로 커밋에 서명하면 GitHub가 커밋 옆에 Verified 배지를 표시합니다. 커밋의 작성자 필드는 임의로 적을 수 있으므로, 서명은 그 커밋이 정말 키 소유자의 것임을 증명하는 수단입니다.
프라이버시 — 프로필과 이메일 #
- 프로필의 기여 그래프에서 private 저장소 활동을 표시할지 선택할 수 있고, Organization 멤버십도 공개·비공개를 고를 수 있습니다.
- 커밋에 실제 이메일을 남기고 싶지 않다면 설정에서 Keep my email addresses private을 켜고, GitHub가 제공하는
noreply주소로 커밋하면 됩니다. 웹 UI에서 만드는 커밋에는 자동으로 적용됩니다.
마무리 #
이번 글의 핵심은 세 가지입니다.
- 저장소 권한은 Read, Triage, Write, Maintain, Admin 5단계이고, push의 경계는 Write, 파급이 큰 설정의 경계는 Admin입니다.
- 인증은 2FA 의무화가 기본 전제이고, 토큰은 최소 권한의 fine-grained PAT가 권장 답안입니다.
- 보안 기능은 감시 대상으로 구분합니다. 의존성은 Dependabot, 비밀키는 secret scanning과 push protection, 코드 패턴은 code scanning입니다.
다음 글 “GitHub Foundations #9 Domain 7: GitHub 커뮤니티 + 시험 팁"에서는 마지막 도메인인 오픈소스·InnerSource·커뮤니티 기능을 정리하고, 시험 직전에 확인할 팁을 함께 다루겠습니다.