06 ‐ 12 ‐ 민감 개인정보 Wrapping 모듈
- 비즈니스 요구사항
- 아키텍처 설계
- API 앤드포인트 설명
- 프론트엔드를 위한 지침서
- 프론트엔드에서 개인정보와 같은 민감한 정보를 서버에 전달할 때, 이 행위 전체를 숨기고, 데이터를 서버에서만 해석이 가능하도록 만드는 역할을 한다.
- 향후에도 지속적으로 민감한 정보들에 대해서는 다음 모듈을 정확히 숙지 및 사용해라.
- 프론트 사이드에서 특정 API 를 실행 시킬 것으로 알린다.
- 서버는 이에 따라 특정 API 에 대응하는 JWT 토큰 생성을 위한 secret 을 발행한다.
- 프론트 사이드는 이를 따라 JWT 토큰으로 어떤
종류의 API 를 전달할지를 암호화하여 전달하고, 서버는 이에 대응 되는 데이터 전송용 secret 을 발행해서 전달한다. - 프론트 사이드는 이를 따라 JWT 토큰으로 특정 API 의 데이터를 암호화하고, 이를 전달한다. 서버는 마찬가지로 데이터의 암호화도 복호화 하여 데이터와 API 행위에 대응 되는 행동으로 이벤트를 처리한다.
- Controller : secret 과 code 를 전달해주는 역할, seed와 code 를 전달해주는 역할을 진행한다.
- Service : 보안 모듈 부분과 각종 API 실행을 위한 DI 된 서비스들로 구성된다.
- 보안 모듈 : JWT 토큰을 위한 key(secret) 생성 부분
- etc parts :
- DTO
- PrivateActions : 최초 apiType을 전달할 때 사용되는 enum, 이 타입을 활용하여 프론트엔드에서 어떤 API 를 실행시키는 지를 복잡하게 만드는 역할을 한다.(실제 내용 코드를 확인할 것)
- 본 API 는 가능하면 데이터의 전달 과전 자체를 모두 모호하고, 해석이 어렵게 만드는 것을 목적으로 제작 되어 있다. 이러한 목적 때문에 다음 API 들은 몇 가지 핵심적인 아이디어를 갖고 있다.
- 모호성 : api 들의 엔드포인트는 명확하여 개발자의 개발에 도움되는 구조를 취하지 않는다.
- 개발 유지 보수성 : 기본적으로 개발의 유지 보수 친화적인 구조를 가지는 것은 개발에 당연한 대주제일 것이고, 지향점이다. 하지만 본 모듈에서는 목표로 삼는 데이터에 대한 외부에서의 접근 자체를 철저히 봉인하며, 특히나 HTTPS 지원을 통해 중간 침입을 막았듯이, 브라우저 상에서 데이터가 어떤 데이터이며, 어떤 절차를 통해 전달되는 지를 최대한 숨기기 위한 목적으로 제작되었다. 따라서 이를 위한 불가피한 개발 유지 보수성은 무시 당하며, 난해함도 묵인되고, 오히려 데이터의 보호가 가장 중요시 된다.
- initKeyForPrivacy :
POST(GET으로 수정 예정)- /main/init
- 최초 어떤 api 를 보낼 것인지를 감추기 위한 용도이며, 최초 요청시 서버에서 발급하는 secret 과 code 를 제공한다.
- 현재는 지정 실수로 POST method 로 지정되어 있으나, 향후 GET으로 수정될 예정이다.
- getKeysForPrivacy :
POST- /main/get
- 1번을 통해 받은 내용으로 JWT 토큰을 만들게 되면, 이 메소드로 전달된다.
- 서버는 프론트 엔드에서 어떤 행위를 하는지 파악한다. 이를 내부 로직에 따라 안전하게 실제 데이터를 암호화 하기 위한
seed와code를 다시 발급하며, 이를 전달해준다. 프론트는 것들을 가지고 실제 데이터를 암호화 한다.
- sendTokenAndKey :
POST- /main/receive
- 2번을 통해 JWT 토큰 데이터와, code 를 받아서 서버 로직을 통해 해석하여 데이터로 변환 및 처리를 해준다.
jwt.io
Json 방식의 Web Token으로 오픈소스이며 RFC7519 부터 표준화된 암호화 방식이다.
기본적인 방식의 구조는 다음 스크린 샷을 참고 하면 된다.
기본적인 구성은 header, payload, verify signature 로 구성되어 있으며, 각각 파트가 다른 역할을 구성하고 있으며, Encoded 된 문자열은 각각 .(온점)으로 부위를 구분하게 된다.
- Header : 알고리즘, type 등을 지정해주는 역할을 하는데, 그 외에도 헤더로써 데이터를 담아 둘 수 있다. 현재 본 모듈은 HS256 알고리즘을 사용하며, 그 외의 값은 본 모듈에서는 필요하지 않다.(모든 JWT 토큰은 해당 모듈에서는 body 에 담아서 전달한다.
- payload : 실질적인 데이터가 담겨야. 기존에 확립된 api 의 데이터 구조를 그대로 활용하므로, 그대로 payload 로 넣으면 된다.
- verify signature : 말그대로 암호화를 하는데 필요한 secret 을 담는 곳이다.
(1) /api/v1/main/init 을 요청하고 secret 과 code 를 받는다
(2) JWT 토큰을 발행하는데 있어 다음처럼 지정한다.
- alg : HS256
- typ : JWT
- payload :
{ "apiType": XXX // number 값 } - verify signature : 받은 secret 값을 입력
(3) 그렇게 생성된 토큰 값, code 를 다시 api/v1/main/get 으로 POST 로 전달한다.
(4) 서버에서 제공해주는 seed와 code 를 다시 받는다. 그리곤 요청할 api body Json 값은 payload 에 넣어 준 뒤, 동일하게 seed 는 verify signature 로 넣어서 JWT 토큰을 만든다.
(5) 생성된 Token과 code 를 다시 api/v1/main/receive/ 으로 POST` 로 전달한다.
기존 지정한 API의 대응값이 전달되며 데이터 교환은 종료 된다.
이때 주의 사항은 다음과 같다.
- 기존의 API가 AccessToken 을 필요한 경우 마찬가지로 첨부해줘야 한다.
- AccesToken이 만료가 되거나, 잘못된 apiType을 집어 넣거나, 집어넣어야 할 데이터가 비정상이어서 성공 외의 결과를 받으면 최초 1번 액션으로 돌아가야 한다.
