클라우드 저장소 만들기 - PK 결정, UUID vs Auto Increment

RDB 테이블의 PK는 무엇으로 할까? (서비스에 MySQL DB를 사용하는 상황이다.)

 

Auto Increment로 하는 것이 가장 간단하고, 용량 차지가 적고, 숫자타입이므로 비교연산이 빠르다.

(다음 편에서 이야기하겠지만, MySQL InnoDB Secondary Index의 구성을 생각해보면

PK의 크기는 가능한 한 작은 게 좋을 것이다.)

 

그래서 기존엔 대부분의 경우 PK로 Auto Increment를 사용했다.

'대부분'에 해당하지 않는 경우는 무엇일까?

 

DB 샤딩과 관련한 문제는 내가 잘 아는 분야가 아니라 넘어가고,

내가 보기엔 '예측 가능한 식별자가 문제되는 경우' 가 

Auto Increment를 사용하기에 문제가 될 수 있는 상황이다.

 

모두가 접근할 수 있는 게시글의 식별자는 예측 가능해도 큰 문제가 없을 것이다.

그런데 인증이 필요한 자원의 식별자가 예측 가능하다면 문제가 생길 가능성이 있다.

바로 '클라우드 저장소  파일'이 그 예시가 되겠다.

 

내가 만드는 서비스는 구글 드라이브와 같다.

모든 사용자에게 열려있는 파일이란 존재하지 않는다. 

모든 사용자에게 공개하려면 최소한 URL 발행이 필요하다.

 

그런데 파일 식별자가 1, 2, 3... 과 같이 Auto Increment로 URL에 노출된다면 어떨까?

내 생각엔 프로그래머가 한치의 실수도 없이 인증 누락을 0%로 유지할 경우엔 보안상 문제되지 않을 것 같다.

하지만 만에 하나 인증 로직이 누락된다면 공격자가 url에 1,2,3..과 같이 식별자를 변경해가며

다른 사용자가 저장한 파일에 접근할 수 있을 것이다. 

 

그러나 실수를 안 하는 것보다는

실수를 할 수 있는 가능성을 틀어막는 것이 중요하다는 말이 있고

요즘 이것을 더 크게 느끼고 있다. 

 

그러므로,

1. 인증이 필요한 자원이며

2. 유출시 문제가 되는 자원

의 경우에는 식별자를 예상 불가능하게 하는 것이 좋겠다고 결론 내렸고

파일의 PK로 UUID를 택했다.

 

다음엔 UUID를 '어떻게' 만들어서 '어떻게' 저장할지 좀 더 자세히 적어 보겠다.