[번역] 마이크로 서비스 보안을 위한 10가지 팁

이번 아티클은 원작자 Scott Matteson의 동의를 얻어서 “10 tips for securing microservice architecture” 글을 번역하였습니다. 참고적으로 10가지 tip 부분은 최대한 원래 의미를 가져가면서 의역을 하였습니다.

원본 : http://www.techrepublic.com/article/10-tips-for-securing-microservice-architecture/

10 tips for securing microservice architecture

마이크로 서비스는 소프트웨어 개발을 가속화하고 개선하는 혁신적인 방법입니다. 이 용어는 개별적으로 개발할 수 있고 종종 특정 기능에 초점을 맞추는 응용 프로그램 하위 구성 요소 (재료 고려)를 나타냅니다. 예를 들어 온라인 쇼핑을 위한 전자 상거래 애플리케이션에는 주문, 계정 액세스, 재고 관리 및 배송과 관련된 여러 가지 마이크로 서비스가 있을 수 있습니다. Twitter, PayPal, Amazon, eBay 및 Netflix와 같은 잘 알려진 전자 상거래 또는 Social 미디어 조직은 마이크로 서비스를 사용합니다.

마이크로 서비스는 컨테이너와 유사하지만 동일하지는 않습니다. 마이크로 서비스는 원자와 같은 분자 및 용기라고 생각하십시오. 마이크로 서비스는 컨테이너에서 실행할 수 있지만 그 반대로는 실행할 수 없습니다. 마이크로 서비스는 응용 프로그램의 전반적인 생태계 또는 아키텍처의 일부로 API (Application Programming Interface)를 통해 서로 통신합니다.

마이크로 서비스에는 몇 가지 장점이 있습니다. 즉, 빠르게 변경 할 수 있고, 재사용 할 수 있으며, 확장 성을 높이고 다른 코딩 언어로 구성 할 수도 있습니다. 전체 프로그램이 아닌 하나 또는 두 개의 마이크로 서비스 만 조정해야 하는 경우 응용 프로그램을 쉽게 업데이트 할 수 있습니다. 이들은 변경을 용이하게 하고 추적하며, 문제를 해결하고 내결함성을 촉진하고 성능을 향상시키는 데 도움을 줄 수 있습니다.

기술의 모든 요소와 마찬가지로 마이크로 서비스에는 보안 위험이 있으며 적절한 사용을 위한 모범 사례도 있습니다. 실질적으로 microservices "원자 내의 분자"개념이 보안을 위해 좋을 것 같습니다. 응용 프로그램 취약성이 가상의 벽 뒤에 sandbox화 되어 있기 때문입니다.

그러나 취약성은 여전히 존재할 수 있으며, 전자 상거래 응용 프로그램 예제의 계정 액세스 마이크로 서비스 - 하나의 마이크로 서비스가 손상 될 수 있음에도 불구하고 여전히 위험을 나타냅니다.   또한 다양한 마이크로 서비스가 복잡성을 증가시키고 특히 응용 프로그램에서 여러 개발자와 메소드를 사용하는 경우 보안을 강화하기가 더 어려워 질 수 있습니다.

NGINX 의 제품 책임자 인 Owen Garrett은 마이크로 서비스 보안에 관해 다음과 같이 말했습니다.

"마이크로 서비스는 모놀리식 아키텍처와는 다른 보안 위험이 있습니다.

통신 변경 (Communication Changes)  : 모놀리식 앱은 마이크로 서비스가 네트워크를 통해 통신하는 동안 프로세스간에 인 메모리 통신을 사용합니다. 네트워크 통신으로의 전환은 속도와 보안 문제를 야기합니다.

데이터 저장소 (Data Stores) : 마이크로 서비스는 많은 데이터 저장소를 사용합니다. 이는 마이크로 서비스와 긴밀하게 결합된 서비스 간의 암시적 통신에 의해 보안 문제를 야기할 수 있습니다.

전문 기술(Technical Expertise) : 마이크로 서비스는 추가적 복잡성을 가지고 있고, 적절한 팀을 구성하지 못하거나 적절하게 관리하지 못할 경우 보안상의 결함을 야기 할 수 있습니다. "

다음은 마이크로 서비스 아키텍처 보안을 위한 10 가지 팁입니다.

1. 각 서비스는 구현 시 재사용 성을 높일 수 있는 반복가능 코딩 표준을 통해 구현하는 것이 좋습니다. 이는 서비스 공통적으로 발생할 수 있는 악용 가능한 취약성 및 문제점에 대한 서비스 구현상 불균형 성을 현격하게 줄일 수 잇습니다.

역자주 : 마이크로 서비스내의 API들은 다양한 기술 및 언어를 통해서 구현할 수 있지만 보안관련되서는 Gateway 서버등의 통제와 같은 공통 기술 표준에 의해 보안성을 유지하는 것이 좋습니다. 서비스 전반에 대한 보안 통제 및 강화를 손쉽게 적용할 수 있기 때문입니다.

2. Less is Better. 보안에서도 마찬가지이다. 최소한의 관점에서 보안측면을 바라보아야 한다.보안을 위해 되도록이면 간략하고 명확하고 설명하기 위한 보안방안을 마련해야 한다.

역자주 : 마이크로 서비스의 장점은 기존 웹 인프라를 그대로 이용할 수 있는 장점이 있습니다.통신 보안등은 기존의 SSL등 인프라를 그대로 이용하여여 복잡성을 줄일 수 있습니다.

3.데이터 기준으로 Access control 기능을 활용하는 게 좋습니다. 가령 재고 확인 서비스 작성시 처음부터 재고 테이블 데이터를 읽고, 쓰기 권한을 가지지 않은 읽을 수만 있는 데이터 접근 권한을 가진 데이터 소스로부터 서비스를 만드는 것이 좋습니다.

역자주 : 이부분은 서비스 구현시 많이 무시되는 부분입니다. 데이터 소스 레벨 부터 적절한 보안 레벨을 적용하고 이용한다면 보안성을 한층 높일 수 있는 방법입니다.

4. 마이크로 서비스 내에 제공되는 코드 내에서 보안 원칙을 유지합니다..즉 예외사항을 만들지 말라는 것입니다.

역자주 : 서비스 구현을 하면서 보안관련된 기능을 구현하거나 확장할 수 있습니다. 이상적으로는 이러한 부분이 없어야 겠지만 현실적으로 별도로 구현할 수 밖에 없는 상황이 발생합니다. 이러한 경우를 위해 서비스 문서화시 이러한 상황을 잘 기술하거나 별도의 서비스에 대한 Tag및 카테고리화 시켜 주의깊게 관리될 수 있도록 신경씁니다.

5. 가능하면 중앙집중 형 보안 정책을 이용하여 일관성을 유지합니다. 관리자에 의해 분석이 많이 들어가는 보안 방법은 좋지 못합니다.

역자주 : 되도록이면 전문 API 서버 솔루션등을 이용하거나 공통 관리 API 통제 서비스 구축을 통해서 구현하는 것이 좋습니다.

6. 개발자간 각자가 구현.서비스를 코드 리뷰 하는 것이 좋습니다.추후에 발생할 수 있는 오류를 줄일 수 있는 방법이기도 합니다.

7. . 각 마이크로 서비스가 어떤 기능을 하는지 완벽하게 문서화되어야 합니다. (예 : 하이재킹되어 스팸을 보내는 데 이용 될 수 있는 오픈 릴레이를 허용하는 Exchange 서버와 통신하는 메시징 마이크로 서비스).

8. 잠재적 인 문제 영역은 물론 취약성 악용 또는 도용을 의미하는 불규칙한 행동을 식별하기 위해 마이크로 서비스 간의 통신 방법론을 완벽하게 기술합니다. 

9. 외부 액세스 (예 : 다른 서버 또는 저장 장치)를 사용하는 경우 전송중인 데이터 (예 : 인증서를 통한 HTTPS를 통한) 및 나머지 데이터의 암호화를 사용해야 합니다.

10. 마이크로 서비스에 대한 정기적으로  코드 및 사용 후기를 수행하여 사용되지 서비스인 경우는 제거해야 합니다.

---

마지막으로 마이크로 서비스 구축에 필수적인 API 솔루션인 DBridge는 이러한 10가지 보안 측면이 고려된 솔루션입니다. 핀테크 관련 서비스 이용 및 KOSCOM 공동 핀테크 오픈 플랫폼 및 기업의 OPEN API 서비스등에 최적화되어 있으며, API 기능 확장을 고려하는 솔루션에서도 유용하게 활용될 수 있습니다.

DBridge API Server : http://www.cyber-i.com/CMS/dbridge.htm