업계에서 다양한 소프트웨어 아키텍처와 애플리케이션을 사용하는 오늘날의 시장에서 데이터가 완전히 안전하다고 느끼는 것은 거의 불가능에 가깝습니다. 따라서 , 개별 서비스가 서로 및 클라이언트와 통신하기 때문에 보안 문제가 더욱 중요해집니다. 따라서 마이크로 서비스 보안에 대한이 기사에서는 다음 순서로 마이크로 서비스를 보호하기 위해 구현할 수있는 다양한 방법에 대해 설명합니다.
마이크로 서비스 란 무엇입니까?
일명 마이크로 서비스 마이크로 서비스 아키텍처 는 애플리케이션을 소규모 자율 서비스 모음으로 구성하는 아키텍처 스타일로, 비즈니스 도메인. 따라서 마이크로 서비스는 단일 비즈니스 로직을 중심으로 서로 통신하는 작은 개별 서비스로 이해할 수 있습니다. 마이크로 서비스에 대해 자세히 알고 싶다면 다음을 수행 할 수 있습니다.
이제 기업이 모 놀리 식 아키텍처에서 마이크로 서비스로 전환 할 때 확장 성, 유연성 및 짧은 개발주기와 같은 많은 이점을 경험하는 경우가 많습니다. 그러나 동시에이 아키텍처에는 몇 가지 복잡한 문제가 있습니다.
따라서 마이크로 서비스 보안에 대한이 기사의 다음으로 마이크로 서비스 아키텍처에서 직면 한 문제를 이해하겠습니다.
마이크로 서비스에서 직면 한 문제
마이크로 서비스에서 직면 한 문제는 다음과 같습니다.
Java에서 tostring은 무엇을 의미합니까?
문제 1 :
사용자가 리소스에 액세스하기 위해 로그인해야하는 시나리오를 고려하십시오. 이제 마이크로 서비스 아키텍처에서 사용자 로그인 세부 정보는 사용자가 리소스에 액세스하려고 할 때마다 확인을 요청하지 않는 방식으로 저장해야합니다. 이제 이것은 사용자 세부 정보가 안전하지 않을 수 있고 또한 3에서 액세스 할 수 있기 때문에 문제가 발생합니다.rd파티.
문제 2 :
클라이언트가 요청을 보낼 때 클라이언트 세부 정보를 확인하고 클라이언트에 부여 된 권한도 확인해야합니다. 따라서 마이크로 서비스를 사용할 때 각 서비스마다 클라이언트를 인증하고 권한을 부여해야 할 수 있습니다. 이제이를 위해 개발자는 모든 서비스에 대해 동일한 코드를 사용할 수 있습니다. 하지만 특정 코드에 의존하면 마이크로 서비스의 유연성이 감소한다고 생각하지 않습니까? 음, 확실히 그렇습니다. 따라서 이것은이 아키텍처에서 자주 직면하는 주요 문제 중 하나입니다.
문제 3 :
다음으로 매우 두드러지는 문제는 각 개별 마이크로 서비스의 보안입니다. 이 아키텍처에서 모든 마이크로 서비스는 3 가지 기능 외에도 동시에 서로 통신합니다.rd파티 응용 프로그램. 따라서 클라이언트가 3에서 로그인하면rd파티 응용 프로그램의 경우 클라이언트가 마이크로 서비스의 데이터에 액세스하지 못하도록해야합니다.
좋습니다. 위에서 언급 한 문제가 마이크로 서비스 아키텍처에서 발견되는 유일한 문제는 아닙니다. 애플리케이션과 아키텍처에 따라 보안과 관련된 다른 많은 문제에 직면 할 수 있습니다. 그 점에서 마이크로 서비스 보안에 관한이 기사를 진행하고 문제를 줄이는 가장 좋은 방법을 알아 봅시다.
마이크로 서비스 보안을위한 모범 사례
마이크로 서비스의 보안을 개선하기위한 모범 사례는 다음과 같습니다.
심층 방어 메커니즘
마이크로 서비스는 세분화 된 수준의 메커니즘을 채택하는 것으로 알려져 있으므로 심층 방어 메커니즘을 적용하여 서비스를보다 안전하게 만들 수 있습니다. 평범한 용어로, 심층 방어 메커니즘은 기본적으로 보안 대책 계층을 적용하여 민감한 서비스를 보호 할 수있는 기술입니다. 따라서 개발자는 가장 민감한 정보로 서비스를 식별 한 다음이를 보호하기 위해 여러 보안 계층을 적용하기 만하면됩니다. 이러한 방식으로 잠재적 인 공격자가 한 번에 보안을 해킹하지 못하도록하고 앞으로 나아가 모든 계층의 방어 메커니즘을 해킹해야합니다.
C ++ stl 정렬
또한 마이크로 서비스 아키텍처에서는 다른 서비스에 대해 다른 보안 계층을 구현할 수 있으므로 특정 서비스를 악용하는 데 성공한 공격자는 다른 서비스의 방어 메커니즘을 해킹하지 못할 수 있습니다.
토큰 및 API 게이트웨이
종종 응용 프로그램을 열면 '사용권 계약 및 쿠키에 대한 권한에 동의'라는 대화 상자가 표시됩니다. 이 메시지는 무엇을 의미합니까? 일단 수락하면 사용자 자격 증명이 저장되고 세션이 생성됩니다. 이제 다음 번에 같은 페이지로 이동할 때 페이지가 서버 자체가 아닌 캐시 메모리에서로드됩니다. 이 개념이 등장하기 전에 세션은 서버 측 중앙에 저장되었습니다. 그러나 이것은 수평 적 확장에서 가장 큰 장벽 중 하나 인 애플리케이션이었습니다.
토큰
따라서이 문제에 대한 해결책은 토큰을 사용하여 사용자 자격 증명을 기록하는 것입니다. 이러한 토큰은 사용자를 쉽게 식별하는 데 사용되며 쿠키 형태로 저장됩니다. 이제 클라이언트가 웹 페이지를 요청할 때마다 요청이 서버로 전달 된 다음 서버는 사용자가 요청 된 리소스에 액세스 할 수 있는지 여부를 확인합니다.
이제 주요 문제는 사용자 정보가 저장되는 토큰입니다. 따라서 토큰의 데이터는 3의 악용을 피하기 위해 암호화되어야합니다.rd파티 자원. Jason Web Format 또는 가장 일반적으로 알려진 JWT는 토큰 형식을 정의하고 다양한 언어에 대한 라이브러리를 제공하며 이러한 토큰을 암호화하는 개방형 표준입니다.
API 게이트웨이
API 게이트웨이는 토큰 인증을 통해 서비스를 보호하기위한 추가 요소로 추가됩니다. 그만큼 게이트웨이는 모든 클라이언트 요청에 대한 진입 점 역할을하며 클라이언트에서 마이크로 서비스를 효율적으로 숨 깁니다. 따라서 클라이언트는 마이크로 서비스에 직접 액세스 할 수 없으므로 어떤 클라이언트도 서비스를 이용할 수 없습니다.
분산 추적 및 세션 관리
분산 추적
마이크로 서비스를 사용하는 동안 이러한 모든 서비스를 지속적으로 모니터링해야합니다. 그러나 방대한 양의 서비스를 동시에 모니터링해야하는 경우 문제가됩니다. 이러한 문제를 방지하기 위해 분산 추적이라는 방법을 사용할 수 있습니다. 분산 추적은 실패를 정확히 찾아 내고 그 원인을 식별하는 방법입니다. 뿐만 아니라 실패가 발생한 위치를 식별 할 수도 있습니다. 따라서 보안 문제에 직면 한 마이크로 서비스를 추적하는 것은 매우 쉽습니다.
세션 관리
세션 관리는 마이크로 서비스를 보호하는 동안 고려해야하는 중요한 매개 변수입니다. 이제 사용자가 응용 프로그램을 사용할 때마다 세션이 생성됩니다. 따라서 다음과 같은 방법으로 세션 데이터를 처리 할 수 있습니다.
- 특정 서버에 단일 사용자의 세션 데이터를 저장할 수 있습니다. 그러나 이러한 종류의 시스템은 서비스 간의로드 밸런싱에 전적으로 의존하며 수평 적 확장 만 충족합니다.
- 전체 세션 데이터는 단일 인스턴스에 저장할 수 있습니다. 그런 다음 네트워크를 통해 데이터를 동기화 할 수 있습니다. 유일한 문제는이 방법에서 네트워크 리소스가 고갈된다는 것입니다.
- 모든 서비스가 동일한 세션 데이터를 읽을 수 있도록 공유 세션 저장소에서 사용자 데이터를 가져올 수 있는지 확인할 수 있습니다. 그러나 데이터가 공유 저장소에서 검색되기 때문에 안전한 방식으로 데이터에 액세스하려면 보안 메커니즘이 있는지 확인해야합니다.
첫 번째 세션 및 상호 SSL
첫 번째 세션의 아이디어는 매우 간단합니다. 사용자는 애플리케이션에 한 번 로그인하면 애플리케이션의 모든 서비스에 액세스 할 수 있습니다. 그러나 각 사용자는 처음에 인증 서비스와 통신해야합니다. 글쎄, 이것은 분명히 모든 서비스 사이에 많은 트래픽을 초래할 수 있으며 개발자가 그러한 시나리오에서 실패를 파악하는 데 번거로울 수 있습니다.
상호 SSL로 인해 애플리케이션은 종종 사용자의 트래픽에 직면합니다. 3rd당사자 및 또한 서로 통신하는 마이크로 서비스. 그러나 이러한 서비스는 3rd파티, 항상 공격의 위험이 있습니다. 이제 이러한 시나리오에 대한 솔루션은 상호 SSL 또는 마이크로 서비스 간의 상호 인증입니다. 이를 통해 서비스간에 전송되는 데이터가 암호화됩니다. 이 방법의 유일한 문제는 마이크로 서비스 수가 증가하면 각 서비스에 자체 TLS 인증서가 있기 때문에 개발자가 인증서를 업데이트하기가 매우 어렵다는 것입니다.
삼rd파티 애플리케이션 액세스
우리 모두는 3 개의 애플리케이션에 액세스합니다.rd파티 응용 프로그램. 3rd파티 애플리케이션은 애플리케이션에서 사용자가 생성 한 API 토큰을 사용하여 필요한 리소스에 액세스합니다. 따라서 타사 애플리케이션은 다른 사용자 자격 증명이 아닌 특정 사용자의 데이터에 액세스 할 수 있습니다. 글쎄, 이것은 단일 사용자에 관한 것입니다. 하지만 애플리케이션이 여러 사용자의 데이터에 액세스해야하는 경우에는 어떻게해야할까요? 그러한 요청이 어떻게 수용 될 것이라고 생각하십니까?
SQL을 배워야하는 이유
OAuth 사용
해결책은 OAuth를 사용하는 것입니다. OAuth를 사용할 때 응용 프로그램은 사용자에게 3rd파티 응용 프로그램에서 필요한 정보를 사용하고 이에 대한 토큰을 생성합니다. 일반적으로 인증 코드는 사용자의 콜백 URL이 도난 당하지 않았는지 확인하기 위해 토큰을 요청하는 데 사용됩니다.
따라서 액세스 토큰을 언급하는 동안 클라이언트는 권한 부여 서버와 통신하고이 서버는 다른 사람이 클라이언트의 ID를 위조하지 못하도록 클라이언트에 권한을 부여합니다. 따라서 OAuth와 함께 마이크로 서비스를 사용하면 서비스가 OAuth 아키텍처에서 클라이언트 역할을하여 보안 문제를 단순화합니다.
글쎄요, 여러분, 이것이 당신의 서비스를 보호 할 수있는 유일한 방법이라고 말하고 싶지 않습니다. 애플리케이션의 아키텍처를 기반으로 여러 가지 방법으로 마이크로 서비스를 보호 할 수 있습니다. 따라서 마이크로 서비스를 기반으로 애플리케이션을 구축하고자하는 사람이라면 서비스의 보안이주의해야 할 중요한 요소 중 하나임을 기억하십시오. 그 메모에서 우리는 마이크로 서비스 보안에 관한이 기사를 끝맺습니다. 이 기사가 도움이 되었기를 바랍니다.
마이크로 서비스를 배우고 자신의 애플리케이션을 구축하려면 다음을 확인하십시오. 강사 주도의 라이브 교육 및 실제 프로젝트 경험과 함께 제공됩니다. 이 교육은 마이크로 서비스를 심층적으로 이해하고 주제에 대한 숙달을 달성하는 데 도움이됩니다.
질문이 있으십니까? ”의 댓글 섹션에 언급하십시오. 마이크로 서비스 보안 ”그러면 다시 연락 드리겠습니다.