Published on

5월 1주 있었던 일 정리

Authors
  • avatar
    Name
    이건창
    Twitter

Introduction

보안 강화

이슈

인증을 이용해 가용성을 HTTPS를 사용해 기밀성을 보장하지만 SSL Strip을 통해 도청할 수 있다.

도청한다면 데이터 위변조가 가능해지고 replay attack이 가능해지는 문제가 있다.

개념

보안에는 가장 기본적인 목표인 기밀성, 무결성, 가용성이 있다.

  • 기밀성 : 데이터가 인가되지 않은 사람에게 노출되지 않아야 한다.
  • 무결성 : 데이터가 변조되지 않아야 한다.
  • 가용성 : 허용된 사람만 이용할 수 있어야 한다.

필자는 보안 3요소를 기준으로 발생하는 영향을 파악하고 해결한다.

데이터 위변조

데이터 위변조인 경우에는 데이터가 변조되는 문제가 있고 무결성을 보장하면 해결할 수 있다. 메시지 정보로 만든 해시 값과 암호화 알고리즘을 이용해 데이터를 변조하지 않았는지 확인한다.

replay attack

replay attack은 허용되지 않는 사용자가 전송하는 문제이므로 가용성을 보장한다면 해결 할 수 있다. 이 때 허용되지 않은 사용자의 정의를 달리한다. 허용된 사용자는 동일한 요청을 보내지 않은 사용자다. 즉, 서비스를 이용하는 사용자라도 해당 규칙을 지키지 못하면 허용되지 않은 사용자가 된다.

상세 설계

해당 문제를 해결하기 위해 해결책을 정리했다.

데이터 위변조 방지

위 개념처럼 무결성을 보장해야 했고, 무결성 알고리즘에서 선택해야 했다. 고려 기준은 대칭키를 이용하거나 비대칭키를 이용하는 방식이 있다.

비대칭키는 대칭키에 비해 안전하지만 키 길이가 길고 수학적 연산이 많기에 느리다. 일반적으로 키 교환을 위해서 사용하기 때문에 요청마다 비대칭키로 무결성을 보장하기엔 부담이 크다.

100만 번 비교할 경우 대략 4배 정도 차이가 난다.

HMAC 실행 시간 (1,000,000번): 9197ms
RSA 실행 시간 (1,000,000번): 38737ms

대칭키의 단점은 키가 노출되면 무결성 보장이 어려워진다. 암호화된 데이터를 복호화하게 되면 데이터를 유추할 수 있기 때문이다. 결국 대칭키를 이용해 모결성을 보장하고 대칭키를 교환 할 수 있게 로직을 구현했다. 그럼 대칭키의 단점을 어느정도 상쇄할 수 있어보인다.

위험도 평가를 통해 어떤 방식을 채택할지도 고민해보면 좋겠다.

replay attack 방지

replay attack 을 방지하기 위해 난수를 사용해서 허용된 사람은 요청을 한 번씩 보낼 수 있다.라는 기준을 세운다. 즉, 요청을 보낼 때마다 난수를 생성해 요청에 포함시키고 서버에서는 해당 난수를 저장해 중복 요청을 차단한다.

그렇다고 모든 난수를 기록하면 부담이 될 수 있다. 그래서 각 요청은 만료 시간을 세우고 난수는 만료 시간보다 적게 측정해 난수 기록 부담을 지웠다. 난수도 결국 무결성을 보장해야 하므로 암호화 대상에 추가됐다.

마무리

작업 과정은 일주일 걸렸으며 게이트웨이에서 무결성 검증을 진행했다. 전달 방식을 결정하면 번복하기 어려웠던터라 관련 레퍼런스를 참고했다.

조금 신경썼던 부분은 엣지케이스와 문서화다. 고려한 엣지케이스는 다음과 같다.

  • 해싱 대상 정확한 기준을 전달 (페이로드가 없는 경우 null 과 빈 문자열 중 어떤 값으로 설정할지)
  • 해싱 대상 데이터 구조 순서 보장
  • 해싱 대상 데이터 구조
  • 해싱 대상 데이터 대상

포스트맨에서 제공하는 문서 생성 기능을 통해 쉽게 문서를 만들었지만 프로세스가 없는 느낌이라 아쉬웠지만 일주일 만에 작업하기 위해서는 만족해야 했다. 업무를 완수한 느낌은 나지만 팀이 더 원활하게 일 할 수 있는 방법을 찾지는 못해서 아쉬웠다.

프로세스

패스트캠퍼스 강의 참고

워크 플로우 분석

먼저 업무 흐름과 구성 요소를 분석한다.

이벤트 식별 -> 태스트 식별 -> 태스트 전환 식별 -> 트리거 식별

발생하는 이벤트를 정리하고 태스크를 정의하게 된다. 정의한 태스크 간 유사성을 찾아 그룹 단위로 묶게 되면 해결해야 할 도메인을 식별할 수 있다. 그렇게 도메인을 식별해 프로세스를 효율적으로 운영한다.

프로세스를 정의하기 위해서는 아래 요소를 기준으로 분석한다.

  • 이벤트 : 발생 이유
  • 트리거 : 이벤트를 발생시킨 명령 식별
  • 액터 : 이벤트를 발생시킨 주체 파악
  • 정책 : 이벤트와 관련된 정책 식별
  • 집합 : 이벤트와 연관된 작업 식별 (연관성은 트랜잭션이나 생명주기로 묶는다.)

정리하자면

생소하거나 복잡한 워크 플로우는 위 요소를 기준으로 분석하게 되면 도메인을 원활하게 식별할 수 있다. 또한 위 요소로 다음 힌트도 얻을 수 있다.

  • 이벤트를 식별해 전후 상황과 진행 과정을 빠르게 파악할 수 있다.
  • 트리거로 발생 시키는 공간과 시간을 파악해 대응 시점을 파악할 수 있다.
  • 액터로 제공 대상자를 파악할 수 있다.
  • 정책은 이벤트가 발생하면서 수행해야 할 행위를 식별하게 한다.
  • 집합으로 작업 단위를 고민해볼 수 있다.

마지막으로

시스템에서 도메인을 정의해봤지 업무 전반적인 도메인 흐름을 고민해본적 없다. 그래서 도메인 주소 설계는 나에게 있어서 독약이었다. 미시적인 관점에서 도메인을 분석하기 위해 작은 흐름을 세세하게 분할해가면서 복잡도만 높였다.

하지만 도메인 주도 설계는 업무 프로세스를 분할해 멀티 태스크가 가능한 구조로 만드는 일임을 깨달았다. 즉, 일부 이벤트를 자동화하기 위해 코드로 변경하며 단순 노무을 줄이는 과정이다.

도메인 주도 설계를 진행할 때 코드 기반으로 생각하는 일을 경계하고 업무 프로세스를 기준으로 효율성을 따져보도록 신경써야겠다. 약간 오해가 있을 수 있으니 정정하자면 하고 싶은 것만 보지 말고 해야할 일에 집중하자라고 알아줬으면 한다.

Discuss on Twitter • View on GitHub