권남

사용자 도구

사이트 도구

추적:
web:신규서비스

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판 		이전 판
다음 판 양쪽 다음 판
web:신규서비스 [2020/07/06 15:58]
kwon37xi [API Gateway] 		web:신규서비스 [2020/11/05 10:41]
kwon37xi [보안]
줄 64: 줄 64:
     * 이는 치명적인 보안 위협이 된다.     * 이는 치명적인 보안 위협이 된다.
     * 특히 인증만 하고, 권한 검사를 제대로 안하고 노출시키는 일이 빈번해서, 인증 받은 특정 사용자가 API Gateway 로 열려있는 내부 API에서 본인이 아닌 다른 사용자의 정보를 읽을 수 있게 된다.     * 특히 인증만 하고, 권한 검사를 제대로 안하고 노출시키는 일이 빈번해서, 인증 받은 특정 사용자가 API Gateway 로 열려있는 내부 API에서 본인이 아닌 다른 사용자의 정보를 읽을 수 있게 된다.
-    * Netflix 의 [[java:zuul|Zuul - Edge Service]] 을 보면, 내부 API를 노출시키는 용도가 아니라, 외부 API인데, 인증 방식이 다른 것들을 API Gateway 로 구성하는 식으로 만든 것이다.+    * Netflix 의 [[java:zuul|Zuul - Edge Service]] 을 보면, 내부 API를 노출시키는 용도가 아니라, 외부 전용 API 서비스인데, 인증 방식이 다른 것들을 API Gateway 로 노출하가게 구성하는 식으로 만든 것이다.
   * 즉, 외부 노출용 API는 그 안에서 사용자를 인증하고, 다른 API를 호출하고, 권한을 검사하는 로직을 다 직접 작성하는 것이 낫다.   * 즉, 외부 노출용 API는 그 안에서 사용자를 인증하고, 다른 API를 호출하고, 권한을 검사하는 로직을 다 직접 작성하는 것이 낫다.
   * 이게 싫다고 **내부용 API 에 권한 로직을 넣는 것도 하지 말라.**   * 이게 싫다고 **내부용 API 에 권한 로직을 넣는 것도 하지 말라.**
줄 70: 줄 70:
     * 이러한 권한을 내부 MSA 서비스 API에 전가하기 시작하면 **MSA 서비스 갯수 * 권한 갯수**의 권한 체크 로직이 분포하게 된다.     * 이러한 권한을 내부 MSA 서비스 API에 전가하기 시작하면 **MSA 서비스 갯수 * 권한 갯수**의 권한 체크 로직이 분포하게 된다.
     * 게다가 그 와중에 또다른 권한 군이 들어오게 되면 모든 MSA 서비스가 그것들을 모두 신경써가면서 개발해야하게 되어 개발 속도를 떨어뜨리고 보안 위협이 시작되게 된다.     * 게다가 그 와중에 또다른 권한 군이 들어오게 되면 모든 MSA 서비스가 그것들을 모두 신경써가면서 개발해야하게 되어 개발 속도를 떨어뜨리고 보안 위협이 시작되게 된다.
 +  * **외부 노출 API가 인증과 권한을 전담해야 한다.**
 ===== 약한 결합도 높은 응집도의 Inteface 기반 개발 ===== ===== 약한 결합도 높은 응집도의 Inteface 기반 개발 =====
   * 각각의 모듈간의 호출은 ''interface'' 기반으로 약한 결합도 높은 응집도를 유지해야 한다.   * 각각의 모듈간의 호출은 ''interface'' 기반으로 약한 결합도 높은 응집도를 유지해야 한다.
줄 244: 줄 245:
   * 회사 규모가 작을 때는 상관없지만 커지면 Github 같은 외부 노출된 저장소 사용시 Key 노출로 인한 보안문제가 발생할 수 있으므로, 사내망에서만 접속 가능한 Source Code Repository를 구축한다.   * 회사 규모가 작을 때는 상관없지만 커지면 Github 같은 외부 노출된 저장소 사용시 Key 노출로 인한 보안문제가 발생할 수 있으므로, 사내망에서만 접속 가능한 Source Code Repository를 구축한다.
   * 코드에서 Validation, 돈 등의 계산은 항상 요청을 받는 서버에서 해야한다. 브라우저등의 클라이언트측 Validation은 단순히 고객 편의를 위해서일 뿐이며, 최종 검사는 항상 서버에서 이뤄져야 한다. Client의 요청은 언제든지 조작 가능하다.   * 코드에서 Validation, 돈 등의 계산은 항상 요청을 받는 서버에서 해야한다. 브라우저등의 클라이언트측 Validation은 단순히 고객 편의를 위해서일 뿐이며, 최종 검사는 항상 서버에서 이뤄져야 한다. Client의 요청은 언제든지 조작 가능하다.
 +  * 요즘엔 다중 기기에서 로그인 유지 상태로 지속적으로 애플리케이션을 사용하는 경우가 있는데, 이 때 사용자의 계정 해킹등이 발생하거나 혹은 기타 다른이유로 해당 사용자로 인증된 모든 기기의 인증을 해제시킬 수 있어야 한다.
 ===== 서버 운영 ===== ===== 서버 운영 =====
   * 절대로 여러 사람이 공유하는 공용 계정으로 서버를 관리하지 말라(AWS 등 포함). 이는 치명적인 보안 사고로 이어진다.   * 절대로 여러 사람이 공유하는 공용 계정으로 서버를 관리하지 말라(AWS 등 포함). 이는 치명적인 보안 사고로 이어진다.
줄 259: 줄 261:
   * 개발팀에서 제어할 수 없는 외부 연동 정보가 있을 경우 해당 정보(특히 API 접속 주소라든가) 등은 [[https://cloud.spring.io/spring-cloud-config/reference/html/|Spring Cloud Config]] 등을 사용하여, 설정 변경을 재배포없이 즉시 적용 가능하게 하는게 좋다.   * 개발팀에서 제어할 수 없는 외부 연동 정보가 있을 경우 해당 정보(특히 API 접속 주소라든가) 등은 [[https://cloud.spring.io/spring-cloud-config/reference/html/|Spring Cloud Config]] 등을 사용하여, 설정 변경을 재배포없이 즉시 적용 가능하게 하는게 좋다.
   * 제어 불가능한 외부 환경의 경우 어떤일이 일어날지 알 수없고, 대응이 언제 될지등도 알 수 없다(예, 갑자기 외부 시스템 운영자의 실수로 API 서버 IP 주소가 바뀌어버렸다).   * 제어 불가능한 외부 환경의 경우 어떤일이 일어날지 알 수없고, 대응이 언제 될지등도 알 수 없다(예, 갑자기 외부 시스템 운영자의 실수로 API 서버 IP 주소가 바뀌어버렸다).
 +  * [[springframework:springboot|SpringBoot]] 처럼 자동 설정이 많고, 업그레이드시 자동 설정값이 바뀌는 경우가 있는 프레임워크 사용시에, 원하는대로 설정이 된 상태로 실서비스가 실행되는지 검증하는 통합 테스트(integration test)를 작성해두는 것이 버전업을 안전하게 할 수 있는 방법이다.
 ===== 서버 모니터링 ===== ===== 서버 모니터링 =====
   * [[:monitoring|서버 모니터링 툴]]을 통해 초반부터 모니터링을 강화한다.   * [[:monitoring|서버 모니터링 툴]]을 통해 초반부터 모니터링을 강화한다.
web/신규서비스.txt · 마지막으로 수정됨: 2024/03/08 11:26 저자 kwon37xi

문서 도구

별도로 명시하지 않을 경우, 이 위키의 내용은 다음 라이선스에 따라 사용할 수 있습니다: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki