AWS S3 접속
S3 서비스로 접속
버킷 만들기 클릭
버킷 만들기 페이지
일반 구성
이름을 지정한다.
객체 소유권
비활성화됨 클릭
이 버킷의 퍼블릭 액세스 차단 설정
이 s3 스토리지는 어느곳에서 접근이 가능하면
디지털 보안이랑 디지털 권리가 아주 침해될 수 있으므로,
s3서버에서는 인코딩 서버와 / 라이센스 서버만 CORS 설정으로 열어 놓아야 한다.
그래서 모든 퍼블릭 엑세스 차단으로 설정
버킷 버전 관리
스토리지를 깃처럼 여러버전으로 관리할 수 있게 했어,
활성화를 하면 문제가 생겼을때 복원이 쉽고, 변경 기록을 찾기 쉽다.
하지만 같은 객체를 여러번 저장하게 될 가능성이 높기 떄문에, 용량은 더 많이 차지한다.
비용이 증가한다는 말이지..
서비스 할 때는 고려해봐야 겠지만, 테스트 환경에서는 비활성화를 하자
기본 암호화
일단 SSE-S3가 비용이 가장낮고, 키를 우리가 관리할 필요가 없어서 테스트 서버에서는
추천되지만, 진짜 서비스 할때는 제어권한이 낮아서 불편할 수 있다.
우린 테스트 환경이니까 SSE-S3를 선택해서 사용하자.
이렇게 생성이 되었다.
IAM 설정
IAM 대시보드로 이동해서
사용자를 클릭
사용자 페이지
사용자 생성 클릭
사용자 세부 정보 지정페이지
권한 설정 페이지
직접 정책 연결 선택
S3 검색해서
FullAccess 선택 누르고 다음페이지
검토 및 생성 페이지
사용자 생성을 하면 s3의 모든 권한을 가진 사용자가 생성이 된다.
엑세스 키 만들기
IAM >> 사용자
로 접속
엑세스 키 만들기 선택
액세스 키 모범 사례 및 대안
CLI 선택 후 다음 페이지
설명 태그 설정
키 만들기 선택
액세스 키 검색 페이지
csv로 다운로드 후 완료를 클릭!
여기 키가 프로젝트에 사용이 될것
다시 S3로 접속
버킷 정보 페이지
아까 생성할 때 퍼블릭 액세스 차단
으로 설정 했기 때문에, 권한이 있는 나만 접속이 가능하지 아무도 못들어온다.
그래서 내가 열어주고 싶은곳만 열어주는 작업을 해야하는데,
우린 웹애플리케이션서버 / 인코딩서버 에서 접근 가능할 수 있도록 만들어줘야된다.
권한을 클릭하자.
버킷 권한 페이지
권한 페이지에서
버킷 정책을 JSON 데이터 형태로 설정할 수 있다.
편집을 클릭
버킷정책 편집
여기서 권한들을 추가할 수 있는데, 선택하면 자동으로 JSON 형태로 생긴다.
여기서 내가 하고 싶은 것은 웹앱서버IP 랑 인코딩 서버 IP를 추가서 허용해야되는 것인데,
localhost같은거는 안된다.
당연하지 서버는 내 상태를 저장하지 않는데, 내가 요청을 해도 그냥 제 3자가 요청하는 것으로 인식하게 될것.
그렇다면 현재로서 할 수 있는 일은,
내 컴퓨터의 외부IP를 등록해야 하고,
만약 프로젝트가 배포가 되어있다면,
그 프로젝트가 포함된 보안 그룹이나 로드밸런서의 IP를 등록해야될 것이다.
만약 그 IP가 변경이 되는 거라면, 매번 다른환경의 IP를 등록해야될 수도 있다.
// 정책 예시
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessFromSpecificIP",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::stephen-busan-bucket/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "내 외부 IP 여기에"
}
}
}
]
}
JavaScript
복사
위에 JSON으로 된 정책 데이터의 의미는
내 컴퓨터 내부에서 서버를 돌려서 요청을 하게 되었을 때 모든 S3요청을 허용하겠다는 뜻이다.
내 외부IP를 aws:SrouceIP 에 등록하면 되는데,
내가 노트북으로 하면 WIFI에 따라 외부IP가 변경이 되니, 매번 등록해줘야 할 수도 있다.
그렇다면 나의 사설 IP가 아닌 외부 IP를 알아내야 한다.
내 컴퓨터 외부IP 알아내는 방법
CMD를 연다.
nslookup myip.opendns.com. resolver1.opendns.com
JavaScript
복사
CMD창에 위의 명령어를 넣어본다.
그럼 이렇게 확인이 가능한데,
내 컴퓨터의 외부 IP는 112.160.228.144 이다.
중요한 것은 wifi가 바뀌면 바뀔 수 있다는 거 명심하고
바뀌면 또 등록해줘야 한다.
편집 JSON데이터 적용하기
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessFromSpecificIP",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::stephen-busan-bucket/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "112.160.228.144"
}
}
}
]
}
JavaScript
복사
자신의 외부 IP를 적용해서
JSON데이터를 복붙하고 변경사항 저장을 클릭한다.
이제 내 아이피에서는 GET/POST/PUT/DELETE가 가능하다.
다시 버킷 >> 권한 페이지 돌아와서 CORS설정
여기서 정하는 CORS는
클라이언트가 사용하고 있는 브라우저에서 해당 리소스를 허용할 것인지 안할 것인지
선택하여 블록을 하기도 하고 허용을 하기도 하는데,
그걸 서버쪽의 CORS설정을 확인해서 클라이언트의 브라우저가
쓸지 안쓸지 판단을 한다.
그래서 한마디로 영상을 플레이 하는 과정에서의 필요한 권한만
서버쪽에서 허용가능하게 설정해주는 것이 좋다.
영상을 플레이라고 한다면 GET요청을 허용한다는 의미이다.
여기서 고민해야할 것은
클라이언트가 직접 S3요청을 하게 할것인지 또는
웹앱서버를 프록시 서버처럼 중계할 것인지
에 대한 고민이다.
일단 테스트 하는 과정에서는 클라이언트가 직접 S3를 요청하게 하는게 간편하다.
그리고 이렇게 할 경우에는 클라이언트가 잠시 동안만 S3 요청권한을 허가받는 설정도 할 수 있다고 한다.
다시 정리해서
프록시 서버로 설계할 경우에는 보안성을 높일 수 있고
클라이언트가 직접 요청하게 할 경우에는 성능을 좀 더 높일 수 있다고 생각하면 된다.
일단 클라이언트가 직접 요청할 수 있도록 코드를 짜겠다. 그럼 CORS설정이 필요하다.
편집을 눌러준다.
CORS편집
역시 JSON데이터 형태로 넣어주면 되는 데,
위의 입력의 의미는
모든 종류와 모든 곳에서 GET요청을 허용하겠다는 뜻이다.
[
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"GET"
],
"AllowedOrigins": [
"*"
],
"ExposeHeaders": [],
"MaxAgeSeconds": 3000
}
]
JavaScript
복사
이걸 복사 붙여넣기 하자.
그렇게 하고 변경사항 저장
일단 서버구축은 완료가 되었다.
코드 구현은 다음 장에서..