마이크로 서비스 아키텍처를 보호하는 11 가지 패턴

마이크로 서비스 아키텍처 보안을 위한 11 가지 패턴과 모범 사례입니다.

1. 의도적으로 안전

처음부터 안전하도록 코드를 디자인하는 것이 합리적이라고 생각합니다. 그러나 악의적인 문자를 제거하는 것이 가장 까다롭습니다. 악의적인 문자는 실제로 사용되는 컨텍스트에 따라 다릅니다. HTML 컨텍스트에 다른 주입 공격 (예 : JavaScript, SQL 등)이 있는지 확인하기 위해 악의적인 문자가 HTML 컨텍스트에 없는지 확인할 수 있습니다. HTML 문서의 인코딩 조차 상황에 따라 달라진다는 점에 유의해야합니다.

또한 문자를 제한하는 것이 항상 실용적이지는 않습니다. 유용한 문자를 제한해야 하는 경우입니다.

이 경우 문자를 제한하려고 시도하는 대신 사용중인 컨텍스트에서 문자가 올바르게 인코딩 되도록하는 것이 좋습니다.

- 롭 윈치

OWASP (Open Web Application Security Project) Top 10은 지난 10년 동안 그렇게 많이 바뀌지 않았습니다. 예를 들어, 방어 엔지니어에게 앱을 보호하는 방법을 교육하는데 사용되는 최고의 접근 방식임에도 불구하고 SQL 삽입이 여전히 가장 일반적인 공격입니다. 우리는 지금 10년 동안 시스템을 노출시킨 것과 같은 실수를 계속 반복합니다.

- 조니 크리스마스

자바로 된 예시를 들어보겠습니다.

public class User {
	private final Long id;
	private final String username;

	public User(final Long id, final String username) {
		this.id = id;
		this.username = username;
	}

	// ...
}

사용자 이름에 문자열 값을 허용하면 누군가 사용자 이름을 사용하여 XSS 공격을 수행 할 수 있습니다.

다음과 같이 입력 유효성 검사로 위의 문제를 해결할 수 있습니다.

import static com.example.xss.ValidationUtils.validateForXSS;
import static org.apache.commons.lang3.Validate.notNull;
public class User {
     private final Long id;
     private final String username;
     public User(final Long id, final String username) {
          notNull(id);
          notNull(username);

          this.id = notNull(id);
          this.username = validateForXSS(username);
     }
}

그러나 이 코드는 여전히 문제가 있습니다.

개발자는 보안 취약점에 대해 생각해야합니다.
개발자는 보안 전문가여야하며 validateForXSS() 의 사용방법을 숙지하고 있어야 합니다.
코드를 작성하는 사람은 현재 또는 미래에 발생할 수 있는 모든 잠재적 약점을 생각할 수 있다고 가정합니다.

더 나은 디자인은 Username의 모든 보안 문제를 캡슐화하는 클래스 를 만드는 것입니다.

import static org.apache.commons.lang3.Validate.*;

public class Username {
	private static final int MINIMUM_LENGTH = 4;
	private static final int MAXIMUM_LENGTH = 40;
	private static final String VALID_CHARACTERS = "[A-Za-z0-9_-]+";
	private final String value;
    
	public Username(final String value) {
		notBlank(value);
		final String trimmed = value.trim();
		inclusiveBetween(MINIMUM_LENGTH, MAXIMUM_LENGTH, trimmed.length());
		matchesPattern(trimmed, VALID_CHARACTERS, "Allowed characters are: %s", VALID_CHARACTERS);
		this.value = trimmed;
	}
    
	public String value() {
		return value;
	}
}

public class User {
	private final Long id;
	private final Username username;
	public User(final Long id, final Username username) {
		this.id = notNull(id);
		this.username = notNull(username);
	} 
}

이러한 방식으로 설계하면 개발자가 보안 코드를 보다 쉽게 작성할 수 있습니다.

로봇 및 임베디드 장치에 더 많은 소프트웨어를 배치함에 따라 보안 코드 작성이 점점 더 중요해지고 있습니다.

2. 스캔 종속성

타사 종속성은 프로덕션에 배포하는 코드의 80%를 구성합니다. 소프트웨어 개발에 사용하는 많은 라이브러리는 타사 혹은 외부 라이브러리에 의존합니다. 전이종속성은 (종종) 대규모 종속성 체인으로 이어지며, 이 중 일부에는 보안 취약점이 있을 수 있습니다.

소스 코드 저장소에서 스캔 프로그램을 사용하여 취약한 종속성을 식별 할 수 있습니다. 배포 파이프 라인, 기본 코드 줄, 릴리스 된 코드 버전 및 기여된 새로운 코드에 대한 취약점을 미리 검색해야합니다.

Jeremy Long의 “ (응용 프로그램) 패치 선언”을 시청하는 것이 좋습니다. 훌륭한 프리젠 테이션입니다. 대화에서 몇 가지 탈취 : Snyk Survey : 25% 프로젝트는 보안 문제를 보고하지 않습니다. 대다수는 릴리즈 노트만 추가합니다. CVE는 10%만 보고합니다.

간단히 말해서 도구를 사용하여 우선 순위를 정하지만 항상 종속성에 맞춰 업데이트 하십시오! - 롭 윈치

GitHub 사용자인 경우 dependabot을 사용하여 풀 요청을 통해 자동 업데이트를 제공할 수 있습니다.

GitHub는 리포지토리에서 활성화 할 수 있는 보안 경고도 제공 합니다.

Snyk 및 JFrog Xray 와 같은 모든 기능을 갖춘 솔루션을 사용할 수도 있습니다 .

3. HTTPS Everywhere 사용

정적 사이트의 경우에도 모든 곳에서 HTTPS를 사용해야 합니다. HTTP 연결이있는 경우 HTTPS 연결로 변경하십시오. Maven 리포지토리에서 XSD에 이르는 워크 플로의 모든 측면이 HTTPS URI를 참조하는지 확인하십시오.

HTTPS의 공식 이름은 전송 계층 보안 (일명 TLS)입니다. 컴퓨터 응용 프로그램 간의 개인 정보 보호 및 데이터 무결성을 보장하도록 설계되었습니다. HTTPS 작동 방식 HTTPS에 대한 자세한 정보를 얻을 수있는 훌륭한 사이트입니다.

HTTPS를 사용하려면 인증서가 필요합니다. 그것은 일종의 운전 면허증이며 두 가지 기능을 제공합니다.

PKI (Public Key Infrastructure)를 통해 암호화 된 통신을 사용할 수 있는 권한을 부여하고 인증서 보유자의 신원도 인증합니다.

Let's Encrypt는 무료 인증서를 제공하고 API를 사용하여 갱신을 자동화 할 수 있습니다.

Sergio De Simone 의 최근 InfoQ 기사 에서 :

Let's Encrypt는 2016년 4월 12일에 시작되었으며 X.509 인증서를 통한 HTTPS 사용과 같이 비용이 많이 들고 긴 프로세스를 간단하고 무료로 널리 사용 가능한 서비스로 만들어 인터넷을 혁신했습니다. 최근에 조직은 설립 이후 전체적으로 10억 개의 인증서를 발행했다고 발표했으며, Let's Encrypt는 인터넷의 보안 웹 사이트 비율을 두 배로 늘린 것으로 추정됩니다.

Let's Encrypt 의 Certbot 을 사용하여 인증서를 얻고 갱신할 것을 권장합니다. Certbot은 수동으로 관리되는 웹 사이트에서 인증서를 자동으로 사용하여 HTTPS를 활성화하는 무료 오픈 소스 소프트웨어 도구입니다. EFF (Electronic Frontier Foundation)는 Certbot을 만들고 유지 관리합니다.

Certbot의 웹 사이트는 당신이 당신의 웹 서버와 시스템을 선택할 수 있습니다. 인증서 생성과 갱신을 자동화하기위한 지침을 제공합니다. 예를 들어, Nginx와 함께 Ubuntu에 대한 지침이 있습니다.

Spring Boot와 함께 인증서를 사용하려면 구성이 필요합니다.

src / main / resources / application.yml

server:
  ssl:
    key-store: classpath:keystore.p12
    key-store-password: password
    key-store-type: pkcs12
    key-alias: tomcat
    key-password: password
  port: 8443

구성 파일에 비밀번호를 저장하는 것은 좋지 않습니다. 아래에서 이와 같은 키를 암호화하는 방법을 보여 드리겠습니다.

HTTPS를 강제 할 수도 있습니다. 이전 블로그 포스트 10 Spring Boot Application을 보호하는 탁월한 방법 에서 이를 수행하는 방법을 볼 수 있습니다. 종종 HTTPS 강제는 HTTP Strict-Transport-Security 응답 헤더 (로 약칭 HSTS)를 사용하여 브라우저가 HTTPS를 사용하여 웹 사이트에만 액세스해야 한다고 알려줍니다.

HTTPS를 로컬로 사용하도록 Spring 기반 마이크로 서비스 아키텍처를 설정하는 방법을 보려면 HTTPS 및 OAuth 2.0을 사용한 안전한 서비스-서비스 스프링 마이크로 서비스를 참조하십시오 .

"네트워크 내부에 왜 HTTPS가 필요한 가요?"

훌륭한 질문입니다! 네트워크 내부에 위협이 있을 수 있으므로 전송하는 데이터를 보호하는 것이 좋습니다.

Johnny Xmas는 최근 InfoQ Podcast 에서 웹 공격이 어떻게 발생하는지 설명합니다 . 사람들의 자격 증명을 피싱하고 추측하는 것은 매우 효과적인 기술입니다. 두 경우 모두 공격자는 네트워크 내 컴퓨터 (관리자 권한)에 액세스하여 혼란을 일으킬 수 있습니다.

안전한 GraphQL API

GraphQL은 HTTP를 사용하므로 보안 관점에서 추가 논리를 수행 할 필요가 없습니다. 가장 필요한 것은 GraphQL 구현을 최신 상태로 유지하는 것입니다. GraphQL은 모든 것에 대한 POST 요청에 의존합니다. 사용하는 서버는 입력 삭제를 담당합니다.

OAuth 2.0 및 React 로 GraphQL 서버 에 연결하려면 Authorization헤더만 전달하면 됩니다.

Apollo는 데이터 그래프를 작성하기위한 플랫폼이며 Apollo Client는 React 및 Angular에 대한 구현을 포함합니다.

const clientParam = { uri: '/graphql' };
const myAuth = this.props && this.props.auth;
if (myAuth) {
	clientParam.request = async (operation) => {
		const token = await myAuth.getAccessToken();
		operation.setContext({ headers: { authorization: token ? `Bearer ${token}` : '' } });
	}
}
const client = new ApolloClient(clientParam);

보안 Apollo 클라이언트 구성은 Angular와 유사합니다 .

export function createApollo(httpLink: HttpLink, oktaAuth: OktaAuthService) {
	const http = httpLink.create({ uri });
	const auth = setContext((_, { headers }) => {
		return oktaAuth.getAccessToken().then(token => {
			return token ? { headers: { Authorization: `Bearer ${token}` } } : {};
		});
	});
    
	return {
		link: auth.concat(http),
		cache: new InMemoryCache()
	};
}

서버에서 RESTQ 엔드 포인트를 보호하기 위해 사용하는 모든 것을 사용하여 GraphQL을 보호 할 수 있습니다.

안전한 RSocket 엔드 포인트

RSocket은 오늘날의 클라우드 네이티브 및 마이크로 서비스 애플리케이션을 구축하기 위한 차세대 반응성 레이어 5 애플리케이션 통신 프로토콜입니다.

무슨 의미냐 하면, 이는 RSocket에 반응성 의미 체계가 내장되어있어 클라이언트와의 안정적인 통신을 제공 할 수 있습니다. RSocket 웹 사이트 구현은 자바, 자바스크립트, Go, .NET, C++, 그리고 Kotlin을 사용할 수 있습니다.

Spring Security 5.3.0은 RSocket 애플리케이션 보안을 완벽하게 지원합니다 .

RSocket에 대한 자세한 내용은 RSocket 시작하기 : 스프링 부트 서버를 참조하십시오.

4. 액세스 및 신원 토큰 사용

OAuth 2.0은 2012 년부터 위임 된 권한을 제공했습니다. OpenID Connect는 2014 년 OAuth 2.0 위에 연합 ID를 추가했습니다.이 코드는 코드를 작성할 수있는 표준 사양을 제공하며 IdP (Identity Providers)에서 작동 할 것이라는 확신을줍니다.

또한 스펙을 사용하면 /userinfo엔드 포인트에 액세스 토큰을 전송하여 사용자의 ID를 찾을 수 있습니다 . 사용자 ID를 얻는 표준 방법을 제공하는 OIDC 감지를 사용하여이 엔드 포인트의 URI를 찾을 수 있습니다.

마이크로 서비스간에 통신하는 경우 OAuth 2.0의 클라이언트 자격 증명 흐름을 사용하여 안전한 서버 간 통신 을 구현할 수 있습니다. 아래 다이어그램에서는 API Client하나의 서버이고 API Server다른 서버 입니다.

인증 서버 : 일대일 또는 일대일?

OAuth 2.0을 사용하여 서비스를 보호하는 경우 인증 서버를 사용하는 것입니다. 일반적인 설정은 일대일 관계로, 하나의 권한 부여 서버와 통신하는 많은 마이크로 서비스가 있습니다.

이 접근법의 장점 :

서비스는 액세스 토큰을 사용하여 다른 내부 서비스와 통신 할 수 있습니다 (모두 동일한 권한 부여 서버에 의해 작성되었으므로)
모든 범위 및 권한 정의를 찾을 수있는 단일 장소
개발자 및 보안 담당자를보다 쉽게 관리
더 빨라짐

단점 :

불량 서비스가 토큰에 문제를 일으킬 가능성을 열어줍니다
한 서비스의 토큰이 손상되면 모든 서비스가 위험에 노출됩니다
모호한 보안 경계

다른보다 안전한 대안은 모든 마이크로 서비스가 자체 인증 서버에 바인딩되는 일대일 접근 방식입니다. 서로 대화해야하는 경우 신뢰하기 전에 등록해야합니다.

이 아키텍처를 사용하면 보안 경계를 명확하게 정의 할 수 있습니다. 그러나 더 수다스럽고 관리하기가 어렵 기 때문에 속도가 느립니다.

나의 추천 : 일대일 관계를 지원하기위한 계획과 문서가 될 때까지 다 대일 관계를 사용하십시오.

JWT에 PASETO 토큰 사용

JWT (JSON Web Tokens)는 지난 몇 년 동안 매우 인기를 얻었지만 불타고 있습니다. 대부분의 개발자가 JWT를 사용하여 세션에 대한 서버 측 스토리지를 피하려고 시도하기 때문입니다. 이것이 권장되지 않는 이유를 알아 보려면 JWT가 세션 토큰 으로 빠지는 이유를 참조하십시오 .

PASETO는 의미 페이지 latform- 영지주의 그 자체 보 안 에 KENS. Paseto는 JOSE 표준을 괴롭히는 많은 디자인 결함없이 JOSE (JWT, JWE, JWS)에 대해 좋아하는 모든 것입니다.

제 동료 랜달 데그 (Randall Degges)와 브라이언 데머 (Brian Demers)는 PASETO에 관한 유익한 게시물을 작성했습니다.

간단히 말해, PASETO 토큰을 사용하는 것은 생각만큼 쉽지 않습니다. 자신의 보안을 작성하려는 경우 가능합니다. 그러나 잘 알려진 클라우드 공급자를 사용하려는 경우 PASETO 표준 (아직)을 지원하지 않을 가능성이 있습니다.

5. 비밀을 암호화하고 보호하십시오

권한 부여 서버 및 기타 서비스와 통신하는 마이크로 서비스를 개발할 때 마이크로 서비스에는 통신에 사용하는 비밀이있을 수 있습니다. 이러한 비밀은 API 키, 클라이언트 비밀 또는 기본 인증을위한 자격 증명 일 수 있습니다.

비밀에 대한 # 1 규칙은 비밀 을 소스 제어에 체크인하지 않는 것 입니다. 개인 리포지토리에서 코드를 개발하더라도 불쾌한 습관이며 프로덕션 코드로 작업하는 경우 문제가 발생할 수 있습니다.

비밀로보다 안전하게하는 첫 번째 단계는 환경 변수에 저장하는 것입니다. 그러나 이것은 시작에 불과합니다. 비밀을 암호화하기 위해 최선을 다해야합니다.

Java 세계에서는 HashiCorp Vault 및 Spring Vault에 가장 익숙 합니다.

동료 Randall은 Amazon KMS의 팬입니다 .

간단히 말해서 작동 방식은 다음과 같습니다.

KMS를 사용하여 마스터 키를 생성합니다
데이터를 암호화 할 때마다 AWS에 새로운 데이터 키 를 생성하도록 요청 합니다. 데이터 키는 AWS는 암호화에 필요한 데이터의 각 부분에 대해 생성 된 고유 한 암호화 키입니다.
그런 다음 데이터 키 를 사용하여 데이터를 암호화
그런 다음 Amazon은 마스터 키 를 사용하여 데이터 키 를 암호화합니다.
그런 다음 암호화 된 데이터 키 를 암호화 된 데이터와 병합하여 암호화 된 메시지 를 만듭니다 . 암호화 된 메시지는 당신이 파일이나 데이터베이스에 저장하는 것 인 것이다 최종 출력이다.

이것이 매우 편리한 이유는 키 보호에 대해 걱정할 필요가 없기 때문입니다. 누군가 데이터를 해독하는 데 필요한 키는 항상 고유하고 안전합니다.

Azure KeyVault 를 사용하여 비밀을 저장할 수도 있습니다 .

6. 배달 파이프 라인으로 보안 확인

종속성 및 컨테이너 스캔은 소스 제어 모니터링 시스템의 일부 여야하지만 CI (연속 통합) 및 CD (연속 전달) 파이프 라인을 실행할 때 테스트를 수행해야합니다.

Atlassian에는 DevSecOps : CD 파이프 라인에 보안 주입 이라는 제목의 유익한 블로그 게시물이 있습니다.

DevSecOps는 DevOps 이니셔티브에 보안을 구축해야 할 필요성을 강조하기 위해 DevOps 대신 많은 사람들이 권장하는 용어입니다. 나는 그것이 혀를 조금 더 쉽게 풀기를 바란다.

Atlassian의 포스트는 보안 단위 테스트, 정적 분석 보안 테스트 (SAST) 및 동적 분석 보안 테스트 (DAST)를 사용할 것을 권장합니다.

코드 전달 파이프 라인은 이러한 보안 검사를 자동화 할 수 있지만 설정하는 데 다소 시간이 걸릴 수 있습니다.

소프트웨어 제공에 대한 "연속 해킹"접근 방식에 대한 자세한 내용은 Zach Arnold 및 Austin Adams의이 기사를 확인하십시오 . 그들은 다음을 권장합니다.

빌드시 확인할 Docker 기본 이미지의 화이트리스트 작성
암호로 서명 된 기본 이미지를 가져와야합니다.
푸시 된 이미지의 메타 데이터를 암호화하여 서명하여 나중에 확인할 수 있도록
컨테이너에서 패키지 관리자의 보안 기능을 사용하여 패키지의 무결성을 확인하는 Linux 배포 만 사용하십시오.
타사 종속성을 수동으로 가져올 때는 HTTPS 만 허용하고 체크섬의 유효성을 검사하십시오.
프로그램 Dockerfile이 민감한 호스트 경로를 볼륨 마운트로 지정하는 이미지를 빌드하도록 허용하지 마십시오

그러나 코드는 어떻습니까? Zach와 Austin은 자동화를 사용하여 분석합니다.

알려진 코드 수준 보안 취약성에 대해 코드베이스에서 정적 코드 분석 실행
자동화 된 종속성 검사기를 실행하여 가장 안전한 최신 버전의 종속성을 사용하고 있는지 확인하십시오.
서비스를 가동시키고 실행중인 컨테이너에 자동 침투 봇을 지시하고 어떤 일이 발생하는지 확인

코드 스캐너 목록은 OWASP의 소스 코드 분석 도구를 참조하십시오 .

7. 공격자 둔화

누군가 수백 개의 사용자 이름 / 암호 조합을 사용하여 API를 공격하려고하면 성공적으로 인증하는 데 시간이 걸릴 수 있습니다. 이 공격을 감지하고 서비스 속도를 늦추면 공격자가 사라질 가능성이 있습니다. 그것은 그들의 시간 가치가 없습니다.

코드 (종종 오픈 소스 라이브러리) 또는 API 게이트웨이에서 속도 제한을 구현할 수 있습니다. 다른 옵션이 있다고 확신하지만 구현하기가 가장 간단합니다.

대부분의 SaaS API는 속도 제한을 사용하여 고객 남용을 방지합니다. Okta는 서비스 거부 공격으로부터 보호하기 위해 이메일 속도 제한과 API 속도 제한이 있습니다 .

8. 도커 루트리스 모드 사용

Docker 19.03은 rootless 모드를 도입했습니다 . 개발자는 Docker 데몬의 보안 공간을 줄이고 사용자가 루트 권한을 얻을 수없는 시스템에 Docker 기능을 노출하도록이 기능을 설계했습니다.

프로덕션에서 Docker 데몬을 실행하는 경우 반드시 살펴보십시오. 그러나 Kubernetes가 Docker 컨테이너를 실행하게하려면 runAsUser에서 를 구성해야 합니다 PodSecurityPolicy.

9. 시간 기반 보안 사용

InfoQ 팟 캐스트에서 Johnny Xmas로부터 얻은 또 다른 팁은 시간 기반 보안을 사용하는 것이 었습니다. Winn Schwartau 는 심층적 인 다이빙을 원하는 모든 사람에게 훌륭한 자료 인 잘 알려진 Time Based Security 책 을 썼습니다 .

시간 기반 보안의 기본 개념은 시스템이 완전히 안전하지 않다는 것입니다. 누군가 침입 할 수 있습니다. 침입자 방지는 시스템 보안의 한 부분 일뿐입니다. 감지 및 반응도 필수적입니다.

다단계 인증을 사용하여 침입자의 속도를 늦추고 높은 권한을 가진 사람이 중요한 서버에 인증하는시기를 감지 할 수 있습니다 (이런 일은 자주 발생하지 않아야 함). 네트워크 트래픽을 제어하는 도메인 컨트롤러와 같은 것이 있으면 로그인이 성공할 때마다 네트워크 관리자 팀에게 경고를 보냅니다.

이것은 이상을 감지하여 신속하게 대응하려는 한 가지 예일뿐입니다.

10. 취약점에 대한 Scan Docker 및 Kubernetes 구성

Docker 컨테이너는 마이크로 서비스 아키텍처에서 매우 인기가 있습니다. Snyk의 친구들이 10 개의 Docker Image Security 모범 사례를 발표했습니다 . 이미 언급 한 내용 중 일부를 반복하지만 여기에 요약하겠습니다.

최소 기본 이미지 선호
USER최소 권한을 사용하도록 지시문을 사용하십시오.
MITM 공격을 완화하기 위해 이미지 서명 및 확인
오픈 소스 취약점 찾기, 수정 및 모니터링 (Snyk는 Docker 이미지도 스캔하고 모니터링하는 방법을 제공합니다)
Docker 이미지에 민감한 정보를 유출하지 마십시오
불변성을 위해 고정 태그 사용
COPY대신에 사용ADD
maintainerand와 같은 메타 데이터 레이블 사용securitytxt
작고 안전한 이미지를 위해 다단계 빌드 사용
hadolint 와 같은 린터 사용

당신은 또한 찾을 수 상위 5 도커 취약점 당신이해야합니다 알고을 유용 WhiteSource에서.

또한 Kubernetes 구성의 취약점을 스캔해야하지만 그보다 훨씬 많은 부분이 있으므로 다음 섹션에서 K8s 보안에 대해 다룰 것입니다.

11. 클라우드 및 클러스터 보안 이해

프로덕션 클러스터와 클라우드를 관리하는 경우 4C의 Cloud Native Security를 알고있을 것입니다 .

4C는 각각 사각형의 보안에 따라 다릅니다. 코드 수준의 보안 만 처리하여 클라우드, 컨테이너 및 코드의 열악한 보안 표준으로부터 보호하는 것은 거의 불가능합니다. 그러나 이러한 영역을 적절히 다루면 코드에 보안을 추가하면 이미 강력한 기반이 강화됩니다.

Kubernetes 블로그에는 Andrew Martin 의 11 Ways (Not) 제목 이 Get Hacked에 대한 자세한 게시물이 있습니다 . Andrew는 해커가 클러스터를 손상 시키면 클러스터를 강화하고 복원력을 높이기 위해 다음 팁을 제공합니다.

어디서나 TLS 사용
최소 권한으로 RBAC 활성화, ABAC 비활성화 및 감사 로깅 사용
타사 인증 제공자를 사용 (구글, GitHub의 같은 - ! 또는 Okta를 )
etcd 클러스터 분리 및 방화벽
암호화 키 회전
Linux 보안 기능 및 제한된 사용 PodSecurityPolicy
YAML을 정적으로 분석
루트가 아닌 사용자로 컨테이너 실행
네트워크 정책 사용 (포드 간 트래픽 제한)
이미지 스캔 및 IDS 실행 (침입 탐지 시스템)
서비스 메시 실행

이 블로그 게시물은 2018 년 7 월부터 작성되었지만 많은 부분이 변경되지 않았습니다. 2018 년 이후 서비스 메시에 대해 과대 광고가 있었지만 큰 차이는 없었습니다.

Istio와 같은 서비스 메시를 실행하면 "전투 테스트를 거친 공유 라이브러리 세트"로 보안을 오프로드 할 수 있습니다. 그래도 블로그 게시물에서 알 수 있듯이 "차세대 네트워크 보안 배포가 간소화 된 것"이라고 생각하지 않습니다.

마이크로 서비스 및 웹 보안에 대해 자세히 알아보기

이러한 보안 패턴이보다 보안에 민감한 개발자가되는 데 도움이 되었기를 바랍니다. 내 목록 중 절반 만이 일상적으로 코드를 작성하는 개발자와 관련이 있다는 것이 흥미 롭습니다.

의도적으로 안전
스캔 종속성
어디서나 HTTPS 사용
액세스 및 신원 토큰 사용
비밀을 암호화하고 보호하십시오

나머지는 DevOps 사용자 또는 DevSecOps에 적용되는 것으로 보입니다.

전달 파이프 라인으로 보안 확인
공격자 둔화
도커 루트리스 모드 사용
시간 기반 보안 사용
취약점에 대한 Scan Docker 및 Kubernetes 구성
클라우드 및 클러스터 보안 이해

이러한 모든 패턴은 중요한 고려 사항이므로 개발자와 DevSecOps 팀간에 밀접한 관계를 유지해야합니다. 실제로 마이크로 서비스를 제대로하고 있다면,이 사람들은 별도의 팀에 있지 않습니다! 이들은 개념에서 생산에 이르기까지 마이크로 서비스를 소유 한 동일한 제품 팀에 있습니다.

더 찾고 계십니까? 마이크로 서비스와 보안 중심의 블로그가 몇 가지 있습니다.

출처 : https://dzone.com/articles/11-patterns-to-secure-microservice-architectures

'Microservices' 카테고리의 다른 글

(Spring Boot and Cloud)를 사용한 마이크로 서비스 구현 (0)	2020.06.25
반응형 마이크로 서비스로 뛰어들다 (0)	2020.06.25

레드레몬씨 정보통신

마이크로 서비스 아키텍처를 보호하는 11 가지 패턴

마이크로 서비스 아키텍처 보안을 위한 11 가지 패턴과 모범 사례입니다.

1. 의도적으로 안전

2. 스캔 종속성

3. HTTPS Everywhere 사용

안전한 GraphQL API

안전한 RSocket 엔드 포인트

4. 액세스 및 신원 토큰 사용

인증 서버 : 일대일 또는 일대일?

JWT에 PASETO 토큰 사용

5. 비밀을 암호화하고 보호하십시오

6. 배달 파이프 라인으로 보안 확인

7. 공격자 둔화

8. 도커 루트리스 모드 사용

9. 시간 기반 보안 사용

10. 취약점에 대한 Scan Docker 및 Kubernetes 구성

11. 클라우드 및 클러스터 보안 이해

마이크로 서비스 및 웹 보안에 대해 자세히 알아보기

'Microservices' 카테고리의 다른 글

티스토리툴바

마이크로 서비스 아키텍처를 보호하는 11 가지 패턴

마이크로 서비스 아키텍처 보안을 위한 11 가지 패턴과 모범 사례입니다.

1. 의도적으로 안전

2. 스캔 종속성

3. HTTPS Everywhere 사용

안전한 GraphQL API

안전한 RSocket 엔드 포인트

4. 액세스 및 신원 토큰 사용

인증 서버 : 일대일 또는 일대일?

JWT에 PASETO 토큰 사용

5. 비밀을 암호화하고 보호하십시오

6. 배달 파이프 라인으로 보안 확인

7. 공격자 둔화

8. 도커 루트리스 모드 사용

9. 시간 기반 보안 사용

10. 취약점에 대한 Scan Docker 및 Kubernetes 구성

11. 클라우드 및 클러스터 보안 이해

마이크로 서비스 및 웹 보안에 대해 자세히 알아보기

'Microservices' 카테고리의 다른 글

'Microservices' Related Articles

티스토리툴바