book

SRE를 위한 시스템 설계와 구축

by 헤더 애드킨스, 벳시 바이어, 폴 블랭킨십, 피오트르 레반도프스키, 애나 오프레아, 애덤 스터블필드, 장현희

January 2022

Beginner to intermediate

624 pages

11h 51m

Korean

Hanbit Media, Inc.

Read now

Unlock full access

1.1 비밀번호와 전기드릴
1.3.1 기밀성1.3.2 무결성1.3.3 가용성
1.4.1 불가시성1.4.2 평가1.4.3 간결성1.4.4 발전1.4.5 회복성1.4.6 설계에서 프로덕션까지
1.4.7 시스템 조사와 로깅1.4.8 위기 대응1.4.9 복구
2.2.1 취미로 즐기는 사람2.2.2 취약점 연구원2.2.3 정부와 법 집행 기관
2.2.4 운동가2.2.5 범죄자2.2.6 자동화와 인공 지능2.2.7 내부자
2.3.1 위협 정보2.3.2 사이버 킬 체인
2.4 위험 평가 시 고려사항
3.1 프로덕션 환경의 안전한 프록시
4.1.1 기능 요구사항4.1.2 비기능성 요구사항4.1.3 기능과 이머전트 속성의 비교4.1.4 예시: 구글 설계 문서
4.2.1 예시: 결제 처리
4.3.1 예시: 마이크로서비스와 구글 웹 애플리케이션 프레임워크
4.4 초기의 속도와 지속적인 속도의 비교
5.1.1 최소 권한
5.1.3 제로 터치5.2 위험에 따라 접근 분류하기
5.3.1 작은 크기의 기능적 API5.3.2 유리 깨기 메커니즘5.3.3 감사
5.3.4 테스트와 최소 권한
5.3.5 접근 거부 진단
5.4 실제 사례: 설정 분산5.4.1 OpenSSH를 통한 POSIX API 사용5.4.2 소프트웨어 업데이트 API5.4.3 커스텀 OpenSSH ForceCommand5.4.4 커스텀 HTTP 리시버 (사이드카)5.4.5 커스텀 HTTP 리시버 (인프로세스)
5.5 인증과 승인을 위한 정책 프레임워크5.5.1 고급 승인 제어5.5.2 승인 프레임워크의 광범위한 사용5.5.3 잠재적인 함정 피하기
5.6.1 멀티파티 승인5.6.2 쓰리팩터 인증5.6.3 비즈니스 사유5.6.4 임시적 접근
5.6.5 프록시
5.7.1 보안 복잡도의 증가5.7.2 협업과 기업 문화에 미치는 영향5.7.3 보안에 영향을 미치는 양질의 데이터와 시스템5.7.4 사용자 생산성에 미치는 영향5.7.5 개발자 복잡도에 대한 영향
6.1.1 시스템 불변성6.1.2 불변성 분석하기6.1.3 멘털 모델
6.2.1 복잡도와 이해 가능성의 관계6.2.2 복잡성의 구분6.2.3 보안과 신뢰성 요구사항의 중앙 집중식 책임
6.3.1 이해 가능한 인터페이스 명세6.3.2 이해할 수 있는 신원, 인증 그리고 접근 제어
6.3.3 더 알아보기: 보안 경계
6.4.1 서비스 요구사항에 애플리케이션 프레임워크를 활용하기6.4.2 복잡한 데이터 흐름의 이해
6.4.3 API 사용성에 대한 고려
7.3.1 디펜던시의 최신 버전을 유지하고 자주 재빌드하자7.3.2 자동화된 테스트를 이용해 빈번하게 릴리스하자7.3.3 컨테이너를 활용하자7.3.4 마이크로서비스를 활용하자
7.4.1 단기적 변화: 제로데이 취약점
7.4.2 중기적 변화: 보안 상태의 향상7.4.3 장기적 변화: 외부의 수요
8.2.1 트로이 목마8.2.2 구글 애플리케이션 엔진 분석
8.3.1 장애 비용의 구분8.3.2 응답 메커니즘의 배포
8.3.3 자동화에는 책임이 따른다
8.4.1 역할 분리8.4.2 위치 분리
8.5 더 알아보기: 장애 도메인과 이중화 (1/2)8.5.1 장애 도메인8.5.2 컴포넌트의 종류
8.5.3 이중화의 제어
8.6.1 검증 집중 분야8.6.2 검증 사례
9.1.1 랜덤 에러9.1.2 실수에 의한 에러9.1.3 소프트웨어 에러9.1.4 악의적인 행위
9.2.1 최대한 빠르게 움직이기 위한 설계(정책에 의한 보호)9.2.2 외부 시간에 대한 디펜던시의 제거
9.2.3 더 알아보기: 롤백은 보안과 신뢰성 사이의 절충이다
9.2.4 더 알아보기: 명시적 폐기 메커니즘 사용
9.2.5 의도한 시스템의 상태를 바이트 수준까지 이해하자
9.2.6 테스트와 지속적 검증을 위한 설계
9.3.1 접근 제어9.3.2 의사소통9.3.3 대응자의 습관
9.5 마치며
10.1.1 공격자의 전략
10.2 방어를 위한 설계10.2.1 방어적 아키텍처10.2.2 방어형 서비스
10.3.1 모니터링과 알람10.3.2 우아한 퇴보10.3.3 DoS 완화 시스템10.3.4 전략적 대응
10.4.1 사용자의 행위10.4.2 클라이언트의 재시도 행위
11.1 공개적으로 신뢰할 수 있는 인증 기관에 대한 배경
11.4.1 프로그래밍 언어 선택11.4.2 복잡도와 이해 가능성의 비교11.4.3 서드파티와 오픈 소스 컴포넌트의 보안11.4.4 테스트11.4.5 CA 키 머티리얼
11.5 마치며
12.1.1 프레임워크를 사용할 때의 장점12.1.2 예시: RPC 백엔드 프레임워크
12.2.1 SQL 주입 취약점: TrustedSqlString12.2.2 XSS 방지: SafeHtml
12.3.1 간단하고 안전하며 신뢰할 수 있는 공통 작업 라이브러리12.3.2 롤아웃 전략
12.4.1 다중 중첩의 방지12.4.2 YAGNI 스멜의 제거12.4.3 기술 부채의 해소12.4.4 리팩터링
12.5.1 올바른 도구의 선택12.5.2 강력한 타입의 사용
12.5.3 코드 새니타이징
13.1.1 효율적인 단위 테스트의 작성13.1.2 단위 테스트의 적절한 사용 시점13.1.3 단위 테스트가 코드에 미치는 영향
13.2.1 효율적인 통합 테스트의 작성
13.4.1 퍼즈 엔진의 동작 원리
13.4.2 효과적인 퍼즈 드라이버의 작성13.4.3 퍼저 구현 예시
13.4.4 지속적 퍼징
13.5.1 코드 검사 자동화 도구
13.5.2 개발자 워크플로에 정적 분석 통합하기
13.5.3 추상 해석
13.6 마치며
14.3.1 코드 검토를 반드시 실행하자14.3.2 자동화를 도입하자14.3.3 사람이 아닌 결과물을 검증하자14.3.4 설정을 코드처럼 관리하자
14.5.1 바이너리 출처14.5.2 출처 기반 배포 정책
14.5.3 검증가능한 빌드
14.5.4 배포 관문14.5.5 배포 사후 검증
14.6.1 한 번에 한 단계씩 진행하자14.6.2 대처 가능한 에러 메시지를 제공하자14.6.3 출처를 명확히 하자14.6.4 정책을 명확히 정의하자14.6.5 배포 유리 깨기 메커니즘을 포함하자
15.1.1 예시: 임시 파일15.1.2 디버깅 기법
15.1.3 막혔을 때 할 수 있는 것들
15.1.4 협력적 디버깅: 가르치는 방법15.1.5 보안 조사와 디버깅의 차이
15.2.1 불변 로그를 설계하자15.2.2 개인정보 보호에 대한 고려15.2.3 기록할 보안 로그 결정하기
15.2.4 로깅 예산
15.3.1 신뢰성15.3.2 보안
16.2 동적 재해 대응 전략
16.4.1 팀원과 역할의 확인16.4.2 팀 헌장의 준비16.4.3 심각성와 우선순위 모델의 준비16.4.4 IR 팀을 위한 운영 매개변수의 정의
16.4.5 대응 계획의 개발16.4.6 상세한 교범의 작성16.4.7 접근 및 업데이트 메커니즘의 도입
16.5.1 시스템의 설정16.5.2 훈련16.5.3 과정과 절차
16.6.1 감사 자동화 시스템16.6.2 비간섭 모의의 수행16.6.3 프로덕션 환경에서의 대응 테스트
16.6.4 레드 팀 테스팅16.6.5 대응의 평가
16.7.1 글로벌에 영향을 미치는 테스트16.7.2 DiRT로 긴급 접근 테스트하기16.7.3 업계 전반의 취약점
17.1.1 사고의 분류17.1.2 손상과 버그의 비교
17.2.1 당황하지 말것17.2.2 대응하기17.2.3 사고 팀의 구성17.2.4 더 알아보기: 운영 보안
17.2.5 제대로 된 OpSec으로 더 나은 결과 얻기17.2.6 더 알아보기: 조사의 과정
17.3.1 사고의 병렬처리17.3.2 교대
17.3.3 팀의 사기
17.4.1 오해17.4.2 얼버무리기17.4.3 회의17.4.4 적절한 사람에게 적정한 수준의 내용 공유하기
17.5.1 분류17.5.2 사고의 선언17.5.3 의사소통과 운영 보안17.5.4 사고 대응의 시작17.5.5 업무 교대17.5.6 업무 재교대17.5.7 의사소통과 복구의 준비
17.6 마치며
18.3 복구 계획18.3.1 복구의 범위18.3.2 더 알아보기: 복구 시 고려사항
18.4.1 자산의 격리18.4.2 시스템 재빌드와 소프트웨어 업그레이드18.4.3 데이터 새니타이제이션18.4.4 데이터 복구18.4.5 자격 증명과 기밀정보의 로테이션
18.5.1 포스트모템
18.6.1 클라우드 인스턴스의 손상18.6.2 대규모 피싱 공격18.6.3 복잡한 복구가 필요한 대상 지정 공격
19.1 배경과 팀의 발전
19.4 속도가 중요하다
20.1.1 전문가의 역할20.1.2 보안 전문성에 대한 이해
20.1.3 자격증과 학계
20.2.1 보안 전문가와 보안 팀의 내재화20.2.2 예시: 구글의 보안 내재화
20.2.3 스페셜 팀: 블루와 레드 팀20.2.4 외부 연구원
21.1.1 자연스럽게 품은 보안과 신뢰성 문화21.1.2 검토하는 문화21.1.3 의식의 문화
21.1.4 긍정의 문화21.1.5 필연성의 문화21.1.6 지속가능성의 문화
21.2.1 프로젝트의 목표와 참여자의 인센티브를 연계하자21.2.2 위험 감소 메커니즘으로 두려움을 줄이자21.2.3 안전망을 표준화하자
21.2.4 생산성과 유용성의 향상21.2.5 많은 의사소통과 투명성 갖추기21.2.6 공감대를 형성하자
21.3.1 의사결정 과정의 이해21.3.2 변화를 위한 사례의 구축21.3.3 자신의 전장을 선택하자
21.3.4 확대와 문제 해결

Overview

시스템이 근본적으로 안전하지 않다면 신뢰할 수 있을까? 보안과 신뢰성은 제품 품질, 성능 및 가용성에 중요한 역할을 하기 때문에 확장되는 시스템의 설계와 운영에 매우 중요하다. 이 책은 안전하고 확장이 가능하며 신뢰할 수 있는 시스템을 설계하는 데 도움을 주는 구글의 구체적인 모범 사례를 자세히 공유한다. 또한, 보안과 안정성에 특화된 실무자의 시스템 설계, 구현 및 유지 보수에 대한 통찰력도 함께 제공한다. 구글러들의 경험으로 얻은 통찰과 SRE 지침을 익혀, 안전하고 신뢰성이 높은 시스템을 구축하길 바란다.

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Start your free trial

Publisher Resources

ISBN: 9791162245033

SRE를 위한 시스템 설계와 구축

by 헤더 애드킨스, 벳시 바이어, 폴 블랭킨십, 피오트르 레반도프스키, 애나 오프레아, 애덤 스터블필드, 장현희

Overview

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

You might also like

클라우드 엔지니어를 위한 97가지 조언

데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링

자바로 배우는 핵심 자료구조와 알고리즘: 기술 면접에 필요한 실용주의 자료구조와 알고리즘

똑똑한 코드 작성을 위한 실전 알고리즘

Publisher Resources