测验：访问控制

프리사인드 URL 이 앱 서버 중계보다 나은 핵심 이유는?

• 앱이 매 요청을 검사하는 것보다 보안이 강해서
• 중계 URL 보다 주소가 짧아서
• 중간 캐시에 잘 얹혀서
• 바이트 전송이 클라이언트와 스토리지 사이에서 직접 일어나 앱 서버가 파이프가 되지 않아서

프리사인드 URL 에 담기지 않는 것은?

• 요청에 서명할 때 쓴 시크릿 키
• 만료 시각
• 허용 동작과 대상 객체
• 요청을 검증하는 서명 값

정책에서 s3:GetObject 만 주고 s3:ListBucket 을 빼면?

• 아무것도 안 된다
• 키를 알면 객체는 읽히지만 목록 조회는 안 된다
• 목록만 되고 읽기가 안 된다
• 쓰기가 된다

Resource 를 arn:aws:s3:::bucket/* 대신 arn:aws:s3:::bucket/img/* 로 좁히는 이유는?

• 정책 평가가 빨라져 응답이 개선된다
• 자격 증명이 유출돼도 피해가 그 접두어 안에 갇히기 때문
• 요청 건수가 줄어 비용이 절감된다
• 대상 키가 적어 목록 조회가 빨라진다

버킷 전체를 익명 읽기로 여는 것이 위험한 실무적 이유는?

• 익명 요청이 늘어 성능이 떨어져서
• 나중에 그 버킷에 공개하면 안 되는 데이터가 섞여 들어가기 때문
• 이그레스 비용이 통제되지 않아서
• 공개 버킷은 목록 조회가 느려져서

프리사인드 PUT URL 을 발급할 때 함께 제한해야 할 것은?

• Content-Length 범위와 Content-Type
• 클라이언트의 다운로드 속도 상한
• 객체가 저장될 리전과 가용 영역
• 객체의 스토리지 클래스와 암호화 방식