Launch HN: Slauth (YC S22) – AWS 및 GCP를 위한 보안 IAM 정책 자동 생성

안녕하세요 HN, 저희는 Daniel과 Bruno이며 다음 서비스를 개발하고 있습니다:

https://slauth.io/. Slauth.io는 AWS 및 GCP를 위한 보안 IAM (Identity and Access Management) 정책을 자동 생성하는 CLI (Command Line Interface)입니다 (며칠 내로 Azure도 지원 예정!). 저희는 개발 팀이 보안 정책 생성을 가속화하고, 클라우드에 과도한 권한이 부여된 정책 (over-permissive policies)이 배포되는 것을 줄일 수 있도록 지원합니다.

영상을 확인하시거나 https://github.com/slauth-io/slauth-cli 에서 샘플 리포지토리 중 하나를 사용하여 저희의 오픈 소스 CLI를 사용해 보세요.

저희는 우연히 클라우드 액세스 시장에 발을 들이게 되었고, IAM에 소비되는 막대한 금액에 놀랐습니다. http://Ermetic.com 및 http://wiz.io/와 같은 현재의 툴들은 배포 후의 IAM 설정 오류 (misconfigurations)를 시각화하지만, 실제 엔지니어링 동작을 변화시키지는 못합니다. 이로 인해 조직은 다음과 같은 끊임없는 루프에 빠지게 됩니다: 엔지니어가 과도한 권한을 가진 정책 배포 ⇒ 보안 엔지니어/CISO(최고 정보 보호 책임자)가 경고를 받음 ⇒ 개발자에게 수정을 요청하는 Jira 티켓 생성 ⇒ 다시 새로운 과도한 권한의 정책이 배포됨.

저희는 수백 명의 개발자와 DevOps 엔지니어를 인터뷰하여 두 가지 핵심적인 고충 (pain points)을 발견했습니다:

1. IAM은 번거로운 작업이다: 개발자들은 IAM의 복잡한 세부 사항을 다루는 것을 매우 싫어합니다.
2. 속도 vs 보안: IAM은 품질 높은 코드를 신속하게 배포하는 속도를 늦추고 있었습니다.

따라서 저희의 목표는 정책 생성을 자동화하여 개발자가 이를 직접 다룰 필요가 없게 만들고, 배포 전 IAM 보안을 강화하는 것입니다.

저희는 어떤 언어로 작성된 코드라도 스캔하기 위해 대규모 언어 모델 (Large Language Models, 현재 OpenAI GPT-4)을 채택하고 있습니다. 일련의 프롬프트 (prompts)를 통해 서비스 호출과 필요한 액션 (actions)을 식별합니다. 리소스 이름은 코드에 내장되어 있지 않은 한 플레이스홀더 (placeholder)로 처리됩니다. 저희는 향후 LLM에 소스 코드를 전송하지 않도록 정적 코드 분석기 (static code analyzer)를 만드는 것을 목표로 하고 있으나, 현재로서는 LLM을 사용하는 것이 시장에 가장 빠르게 진입하는 방법이며 Github Copilot 등을 통해 업계에서도 어느 정도 수용되고 있는 방식입니다.

터미널에서 CLI를 사용할 수도 있고, 실제로 CI/CD에 통합하여 개발 팀의 워크플로 (workflow)의 일부로 만들 수도 있습니다.

저희가 받는 세 가지 주요 질문은

1. 보안 우려 (Security Concerns): Slauth.io가 제 소스 코드에 접근하는 것을 어떻게 신뢰할 수 있나요?
2. 정책 정확도 (Policy Accuracy): Slauth.io가 올바른 정책을 생성한다는 것을 어떻게 신뢰할 수 있나요?
3. 차별점 (Differentiation): IAMLive, IAMBic AccessAnalyzer 또는 Policy Sentry와 비교했을 때 어떤 점이 다른가요?

첫 번째 우려 사항을 해결하기 위해, 저희는 귀하의 코드에 직접 접근하지 않습니다. 대신, 귀하의 CI/CD 파이프라인에 통합되어 로컬 코드 스캐닝 (code scanning)을 허용하는 CLI를 제공합니다. http://slauth.io/는 귀하의 OpenAI 키를 사용하여 코드를 보안 정책으로 변환하며, 결과를 stdout 또는 파일로 출력하여 아티팩트 (artifact)를 업로드하거나 다운로드할 수 있는 옵션을 제공합니다. 이는 정책을 생성하기 위해 어떤 SDK 호출이 수행되는지 알아야 하므로, 스캔하도록 설정한 경로에 위치한 소스 코드에 대해 OpenAI가 접근할 수 있음을 의미합니다.

저희는 AWS, TypeScript 및 GPT 4를 대상으로 광범위하게 테스트를 진행하였으며 매우 좋은 결과(95% 이상의 정확도)를 얻었습니다. GPT 3.5를 사용할 때는 이러한 정확도가 떨어진다는 것을 알고 있으므로, 저희가 프롬프트 (prompts)를 개선하고 있는 만큼 가능하다면 GPT 4를 사용해 주세요. GCP와 Azure는 테스트를 덜 진행했지만, GPT 4를 사용할 때의 결과는 마찬가지로 높은 것으로 보입니다. 또한 약간의 환각 (hallucinations) 현상을 경험하기도 했으나, 이는 보안 정책의 결과물에는 영향을 미치지 않았고 단지 정책이 생성되는 구조에만 영향을 미쳤습니다. 그렇다고 해서 100% 신뢰할 수 있다는 뜻은 아니기에, 저희는 정책 시뮬레이터 (policy simulators) 및 기타 수단을 통해 정책을 재확인할 수 있는 도구들을 제공하는 것을 목표로 하고 있습니다.

경쟁사들과 비교했을 때, 저희는 배포 전 (pre-deployment) 보안 정책을 생성하고 가능한 한 많은 부분을 자동화하는 데 주로 집중하고 있습니다. 저희는 IAMLive에서 영감을 받았지만, 개발 팀 전체에서 사용하기에는 확장성 (scalability)이 부족했습니다. Policy Sentry는 템플릿 제작에는 훌륭하지만, http://Slauth.io를 사용하면 실제로 세분화된 최소 권한 (least privilege) 정책을 얻을 수 있습니다. 마지막으로, Access Analyzer는 이미 배포된 보안 정책을 강화 (harden)하는 데 사용되는데, 이는 다른 클라우드 스캐닝 도구들과 유사하며 보안에 대해 기묘한 사후 대응적 (reactive) 프로세스를 만듭니다. 새로운 access-analyzer 기능은 CDK 내의 정책 차이점 (policy diffs)을 확인하지만, 이 역시 배포 전 (pre-deployment)에 실제로 정책을 생성해주지는 않습니다.

일부 엔지니어들이 보안 정책을 생성할 능력이 매우 뛰어나다는 점을 저희도 인지하고 있습니다. 하지만 IaC 배포 맥락에서 Checkov나 TFscan을 사용하는 것과 마찬가지로, 클라우드에 IAM 설정 오류 (misconfiguration)가 나타나지 않도록 서비스 권한을 배포할 때 CI/CD 과정에서 Slauth.io를 사용하는 것이 필수적이 될 것이라고 믿습니다.

여러분의 피드백을 받고 싶으며, 저희 Github 리포지토리에서 자유롭게 소통하거나 Slack 커뮤니티에 참여해 주세요.