(더욱 안전한) 서비스로서의 기능

애플리케이션 아키텍처와 개발에 대한 여러 가지 현대적인 접근 방식은 기본적으로 "더 작게 만들어 더 효율적으로 만든다"는 형태를 취합니다.

마이크로서비스와 서비스로서의 기능(FaaS)은 모두 고도로 집중된 코드라는 개념에 의존합니다. 사실 대부분 조직이 애플리케이션을 수백 개의 마이크로서비스나 수천 개의 기능으로 분해하지는 않지만 이러한 디자인을 선호하는 경향이 있습니다. 이는 비교적 작은 팀이 대규모 모놀리식 애플리케이션보다 훨씬 더 빠르게 서비스를 설계, 개발, 개선할 수 있기 때문에 Agile 개발이 용이해지기 때문입니다. 결국, 1000줄의 코드로 이루어진 대규모 애플리케이션을 작성하고 테스트하는 것보다 100,000줄의 코드를 작성하고 테스트하는 것이 훨씬 쉽습니다.

하지만 마이크로서비스와 FaaS의 또 다른 흥미로운 이점이 있는데, 널리 알려지지 않았습니다. 바로 보안입니다.

인터넷에는 "업계 평균" 결함 및 취약성 밀도를 파악하려는 논의가 많이 있고 저는 그 중 상당수를 읽었습니다. 오픈소스 코드를 실제로 스캔한 결과를 기반으로 한 추정치도 있고, 자체 보고한 숫자를 기반으로 한 추정치도 있어 다양한 추정치가 나와 있습니다. 예를 들어 NASA는 우주 왕복선 프로그램의 성공 이유 중 하나로 극히 낮은 결함 밀도를 자랑스럽게 선전했습니다. WhiteHat과 같은 보안 회사에서 객관적으로 수집한 데이터를 기반으로 한 보고서도 있지만, 그 수치는 코드 줄당 이 아닌 애플리케이션당 취약점에 초점을 맞추고 있습니다.

결함과 취약성 밀도에 대한 실질적인 합의는 없지만, 결함과 취약성 밀도가 있다는 것에는 동의합니다.

그러나 작성하는 코드 줄이 적을수록 결함과 취약점이 발생할 가능성도 적어지는 것은 당연합니다. 더욱 중요한 점은 취약점이나 결함을 찾기 위해 검색해야 하는 코드 줄이 적을수록 더 빨리 해당 취약점을 찾고, 아마도 수정할 수 있을 것이라는 것입니다.

이것이 사실인 이유 중 하나는 범위 때문입니다. 내 마이크로서비스나 기능이 비즈니스 로직의 한 측면을 체계화하는 데 초점을 맞춘다면, 구현해야 할 로직과 라이브러리가 덜 필요합니다. 범위가 작다는 것은 추가 논리를 구현하는 데 필요한 라이브러리(타사 또는 기타)에 논리 오류나 취약성이 발생할 가능성이 적다는 것을 의미합니다. 다른 구성 요소를 포함시키거나 다른 서비스를 호출해야 할 때마다 결함과 취약점이 발생할 가능성이 생깁니다.

함수나 마이크로서비스에 대한 인터페이스가 적을수록 코드의 보안도 향상됩니다. 모든 인터페이스(API 호출과 같은 진입점)는 사용자 입력을 처리하기 때문에 취약점이 발생할 가능성이 있습니다. 그리고 사용자 입력은 우리가 모두 알고 있듯이 항상 의심스럽고 잠재적으로 악의적인 것으로 처리되어야 합니다 .

그리고 마이크로서비스가 취약점과 결함의 가능성을 줄인다면, 기능의 범위를 더욱 줄이는 것은 그 가능성을 더욱 줄이는 데 도움이 될 것입니다.

하지만 이는 마이크로서비스와 FaaS가 3계층이나 모놀리식 대응 제품보다 본질적으로 더 안전하다는 것을 의미하지는 않습니다. 엉성한 코드는 줄이 몇 개나 되든 엉성한 코드일 뿐입니다. 하지만 두 아키텍처 모두 더 안전한 코드를 만들 수 있는 개발 및 제공 관행에 적합하다는 것은 사실입니다.

마이크로서비스 및/또는 FaaS를 평가하거나 구현할 때 보안상의 이점을 염두에 두면 코드가 커지는 것을 방지하고 취약점 도입을 방어하는 데 실제로 도움이 될 수 있습니다.