보안#
인증과 권한 부여#
- 인증 : 자신이라고 말하는 당사자를 확인하는 과정
- 권한 부여 : 권한 주체를 허용된 행위와 매핑하는 메커니즘
SSO, single sign-on
권한주체가 웹 기반의 인터페이스를 통해 리소스에 접근하려 할 때 그사람은 인증을 위해 신원 제공자(identity provider)에 재전송된다. 신원 제공자는 그 사람에게 사용자 이름과 비밀번호를 요구하거나 이중 요소 인증(two-factor authentication)과 같은 더 진보된 것을 요구할수 있다. 신원 제공자는 권한주체의 인증이 충족되면 그 사람의 자원 접근 허용 여부를 결정하도록 서비스 제공자(service provider)에 정보를 전달한다.
SSO 게이트웨이#
SAML, Security Assertion Markup Language : 보안 보장 생성 언어, 사멜
신원 제공자와 서비스 제공자 간의 인증과 권한부여 데이터를 교환하기 위한 XML 기반 공개 표준 데이터 포맷
- 인증에 대한 책임을 게이트웨이에서 갖는 구조.
- 서로 격리된 마이크로서비스가 어떻게 동작할지 추론이 어렵다.
- 게이트웨이 단일 지점 장애시 전체 서비스에 장애를 줄 수 있다.
세분화된 권한 부여#
- 게이트웨이는 상당히 효과적인 큰 단위의 인증 기능을 제공하는 것이 가능하다.
- 마이크로서비스에 해당 권한을 부여할 수 있도록 한다.
- 일반적으로 조직의 업무 방식을 모델링한 대분류의 역할을 장려하자.
서비스 대 서비스 인증과 권한부여#
경계 안의 모든 것 허용하기
- 보통 내부망을 이용하는 방법으로 사용. 데이터의 민감도에 따라 선택.
- 특정 경계 내부의 모든 호출을 암묵적으로 신뢰한다고 가정.
- 중간자 공격에 대해 무방비 상태.
HTTP(S) 기본 인증#
- 클라이언트가 사용자 이름과 패스워드를 표준 HTTP 헤더에 넣어서 전송하는 것
- HTTPS를 사용함으로 클라이언트는 통신하고 있는 서버 간 보장을 받고, 서버간의 트래픽을 가로채거나 페이로드 조작을 막음
- 여러 머신에 대한 SSL 관리는 문제가 있음
- 자체 인증서의 경우 쉽게 폐기 하기 어려움
- reverse proxy의 경우 캐시 처리가 안됨
클라이언트 인증서#
- TLS(Transport Layer Security) 기능을 이용하는 방법
- 클라이언트와 서버의 연결을 체결할 때 사용되는 X.509 인증서가 각 클라이언트에 설치되어 있으며, 서버는 서버는 클라이이언트 인증서 검증을 통해서 검증이 가능하다
- 서버 인증에 대한 확인이 어렵다
HTTP 기반의 HMAC#
- HTTPS의 대한 트래픽 부담과 캐시가 어려움을 보안한 방법이다
- oAuth 명세서 일부와 AWS의 S3 API에 의해 많이 사용되는 해시 기반 메시징 코드 (hash-based messaging code, HMAC)를 HTTP 요청의 서명에 사용하는 것
- HMAC에서 요청 메시지 비밀키를 사용해서 해시하고, 해시 결과는 요청과 함께 전송됨.
HTTP 기반의 HMAC 장단점
- 장점
- 트래픽이 쉽게 캐시됨.
- 보통 해시를 생성하는 부하가 HTTPS 트래픽을 처리하는 것보다 낮음
- 단점
- 클라이언트와 서버 모두 어떤 방식으로든 통신을 통해서 secret을 공유해야함.
- 하나의 패턴으로 비표준이다.
- 제3자가 요청 내용을 조작하지 않았다는 것과 비밀 키 자체의 기밀성만 보장함. ( 스누핑 노출 )
스누핑, snooping
네트워크상의 정보를 획득하는 일련의 행위를 의미하며 스니핑(sniffing)와 유사한 의미를 가지지만 주로 염탐하는 행위을 의미한다.
API 키#
- API 키를 통해서 서비스는 API 호출자를 인식할 수 있고 호출자의 능력에 제한을 둘 수 있다.
- 게이트웨이 모델에서 많이 사용
SSO와 API게이트웨이 간 권한주체 정보 동기화 (디렉토리 서비스 이용)#
대리인 문제#
인증만을 위한 마이크로서비스가 있을 때, 서비스 대 서비스 통신에서 악의적인 당사자가 대리인 서비스를 속여 하위 서비스에 대한 인가되지 않은 호출을 하는 취약점이 존재
혼동되는 대리인 문제#
보관 중인 데이터 보호하기#
보관 중인 데이터 보호하기
- 잘 알려진 것을 사용하라
- AES-256 등
- 패스워드는 솔트를 이용한 패스워드 해싱 (salted password hashing)을 고려하자.
- 키가 전부다
- 키에 대한 수명 주기 관리를 위한 시스템을 이용하자.
- SQL Server가 제공하는 무명한 데이터 암호화 (TDE, Transparent Data Encryption)
- 암호화 대상 정하기
- 요구형 복호화
- 데이터를 처음 볼때 바로 암호화하고, 복호된 데이터는 저장하지 않는다.
- 백업 암호화하기
심층 방어#
- 방화벽
- 단순 포트를 이용한 방법도 있으나, 다중 방화벽을 이용하는 방법도 추천한다.
- 로깅
- 좋은 로깅은 예방을 위한 것이 아니라, 나쁜일의 탐지와 회복에 도움을 준다.
- 민감한 정보가 로그를 통해 유출되지 않도록 유의한다.
- 침입 탐지와 방지시스템
- 침입 탐지 시스템 (IDS, intrusion detection system) : 문제가 발견될때 리포팅하며 수상한 행위에 대해 네트워크와 호스트를 모니터링 가능.
- 침입 방지 시스템 (IPS, intrusion prevention system) : 수상한 활동을 모니터링할 뿐만 아니라 발생을 막음
- 처음 시작 한다면, IDS를 고려하자. 문제 경보면에서 조율할 기회가 있다.
- 네트워크 분리 ( 망분리 )
- 운영 체제
정리#
Tip
시스템을 작은 서비스들로 분해하면 문제를 해결하는 방법도 그만큼 다양해진다.
마이크로서비스는 잠재적으로 특정 보안 결함을 줄일 뿐만 아니라 민감한 데이터 장소를 위한 더 복잡하고 안전한 방식과 위험도가 낮을 때를 위한 가벼운 방식에 따른 오버헤드를 절충할 방법을 제공한다. 시스템 각 부분의 위협 수준을 이해하게 되면 보안을 전송 시나 보관 중 언제 적용해야 할지, 혹은 전형 신경 쓸 필요가 없는지 판단할 수 있을 것이다.
이것만은 꼭#
- 심층 방어의 중요성을 이해하고 반드시 운영 체제를 패치하자.
- 독자적인 암호화 알고리즘을 구현하지 말자.
- 브라우저 기반의 애플리케이션 보안에 대한 부분은 공개 웹 애플리케이션 보안 프로젝트 (OWASP, Open Web Application Security Project)를 참고하자. ( 10대 보안 위협 )
Reference : Build Microservice By Sam Newman, Publisher: O’Reilly