[3/26] ARIA-gv 워크플로 세션 후기

이번 세션은 개인적으로 “보안에서 가시성이 왜 중요한가”를 굉장히 직관적으로 보여준 발표였다.

 

주제는 풀어쓰면 AWS Identity Center 주변의 권한 구조를 그래프 형태로 시각화하는 접근이다.
처음 들으면 “권한 정보를 굳이 그래프로?”라는 생각이 들 수 있는데, 발표를 듣고 나면 왜 이런 접근이 필요한지 꽤 설득력 있게 다가온다.

 

특히 멀티 계정 환경에서 사용자, 그룹, Permission Set, 계정, IAM Role 관계가 꼬이기 시작하면
문서나 콘솔 화면만으로는 답하기 어려운 질문이 생긴다.

• 우리 회사에서 누가 어떤 계정에 접근할 수 있는가
• 특정 사용자는 실제로 어떤 권한을 갖고 있는가
• 그룹이 중첩되고 권한이 누적될 때 최종 권한은 어떻게 보이는가
• 사고가 발생했을 때 공격자가 어디까지 영향력을 확장할 수 있는가

이번 세션은 바로 이런 질문에 답하기 위한 구조를 설명한 발표였다.
발표자는 권한 관계를 단순 텍스트나 표로 보는 대신, 그래프 기반으로 한 번에 추적 가능한 구조로 바꾸는 것이 핵심이라고 설명했다.

---

왜 굳이 그래프인가

세션에서 가장 먼저 공감됐던 부분은 이거였다.

권한 구조는 원래부터 관계형이다.
사용자가 있고, 사용자는 그룹에 속하고, 그룹은 Permission Set에 연결되고, Permission Set은 특정 계정에 프로비저닝되며, 그 결과 IAM Role이 생기고, 그 역할을 통해 리소스 접근이 가능해진다.
즉, 이건 처음부터 “관계”의 문제다.

RDB로도 저장은 가능하다.
하지만 관계가 많아질수록 조회할 때 조인이 계속 늘어나고,
“이 사용자가 실제로 어디까지 갈 수 있지?” 같은 질문에 답하려면 점점 복잡해진다.

그래프 DB는 여기서 장점이 있다.

• 노드: 사용자, 그룹, Permission Set, 계정, 역할 같은 객체
• 엣지: 소속, 할당, 프로비저닝, 접근 가능 같은 관계

이렇게 구성해두면 복잡한 조인 대신 경로 탐색으로 관계를 따라갈 수 있다.
발표에서도 그래프 DB를 쓰는 이유를 “관계가 많은 데이터를 한 줄의 경로 탐색 쿼리로 확인할 수 있기 때문”이라고 설명했다.

결국 이 세션이 말하고 싶었던 건 단순히 “Neptune 써라”가 아니라,
권한 구조처럼 관계가 복잡한 데이터는 그래프로 봐야 한다는 점이었다.

---

이 세션의 목표: “누가, 어디에, 어느 수준으로 접근 가능한가”

발표의 핵심 목표는 아주 명확했다.

우리 회사에서 누가 구체적으로 어떤 계정에 어떤 수준의 권한으로 접근할 수 있는가를 가시화하는 것.

이 문장이 사실 이 세션 전체를 설명한다.

보안 운영에서는 늘 이런 요청이 생긴다.

• A 사용자가 어느 계정에 접근 가능한지 보여달라
• 특정 그룹이 너무 많은 권한을 갖고 있는지 확인해 달라
• 퇴사자/이동자 권한이 남아 있지 않은지 보고 싶다
• 이 Permission Set이 어디에 퍼져 있는지 알고 싶다

문제는 이런 질문이 늘 발생하는데, 그때마다 사람이 콘솔을 뒤져서 유추해야 하는 경우가 많다는 점이다.
발표자는 바로 이 비효율을 줄이기 위해 그래프 시각화를 제안했다.

---

전체 워크플로: 수집 → 변환 → 적재 → 시각화

발표에서 설명한 ARIA-gv 구조를 정리하면 대략 아래 흐름이다.

1. Step Functions로 권한 데이터 수집

AWS Organizations, Identity Center, IAM 관련 API를 호출해
사용자, 그룹, Permission Set, 계정 등의 데이터를 수집한다.
수집 과정은 Step Functions 안에서 여러 Lambda가 나눠서 처리한다.

2. DynamoDB에 중간 저장

수집한 데이터를 우선 DynamoDB에 넣는다.
이 시점에는 그래프가 아니라, 일단 객체와 관계 정보가 key-value 형태로 저장된 상태다.

3. Neptune이 이해할 수 있는 CSV로 변환

다음 Step Functions가 DynamoDB의 데이터를 읽어서
Neptune 적재 포맷에 맞는 CSV로 바꾼다.
즉, 노드와 엣지를 그래프 DB가 이해할 수 있게 재구성하는 단계다.

4. S3를 거쳐 Neptune 적재

CSV를 S3에 저장한 뒤 Neptune에 적재한다.
이 과정을 통해 비로소 “관계가 연결된 그래프”가 완성된다.

5. SageMaker Notebook에서 시각화

발표에서 SageMaker는 ML 학습용이 아니라,
웹 기반 시각화 인터페이스 역할로 사용됐다.
Neptune의 그래프를 텍스트 쿼리 결과가 아니라 시각적으로 탐색할 수 있게 하는 용도다.

이 구조를 보면 알 수 있듯, 이 솔루션의 핵심은 단순 저장이 아니라
권한 관계를 그래프 형태로 바꿔서 사람이 이해 가능한 방식으로 보여주는 것이다.

---

Step Functions가 두 번 쓰이는 이유

발표에서 흥미로웠던 포인트 중 하나는
Step Functions가 “한 번”이 아니라 두 단계 역할로 나뉜다는 점이었다.

첫 번째 Step Functions는 데이터 수집이다.

• DynamoDB 테이블 생성
• 사용자, 그룹, Permission Set, 계정 같은 기초 객체 병렬 수집
• 그룹 멤버십, 계정-권한 연결 같은 교차 관계 수집

이 단계가 끝나면 DynamoDB에는
Identity Center 내부의 노드와 엣지 후보 데이터가 모인다.

두 번째 Step Functions는 그래프용 변환이다.

• DynamoDB 데이터 읽기
• Neptune용 CSV 생성
• 기존 그래프 초기화
• 새 CSV 적재

즉 첫 번째는 “모으는 단계”, 두 번째는 “그래프로 바꾸는 단계”라고 보면 된다.

이 설명을 들으면서 느낀 건,
실무에서는 결국 원본 데이터와 시각화 데이터 모델이 다르다는 점이다.
원천 데이터 수집만 잘한다고 끝나는 게 아니라,
그걸 사람이 탐색하기 좋은 형태로 다시 설계해야 한다.

---

시각화의 진짜 가치: 사람의 이해 속도를 바꾼다

세션에서 가장 와닿았던 문장은
이 솔루션의 가치가 직관적인 가시성이라는 점이었다.

보안 정책은 원래 글자다.
IAM 정책, 그룹 연결, 권한 구조 전부 텍스트다.
기술적으로는 읽을 수 있지만, 문제는 사람이 빠르게 이해하기 어렵다는 데 있다.

그래프 시각화는 여기서 차이를 만든다.

예를 들어,

• Alice라는 사용자를 클릭한다
• Dev Team 그룹이 나온다
• 거기서 S3 Read Only Permission Set이 보인다
• 그 Permission Set이 연결된 계정과 역할을 더블 클릭해 따라간다

이런 식으로 하나씩 퍼즐처럼 관계를 추적할 수 있다.
발표에서도 전체를 한 번에 보는 것보다,
원하는 객체를 중심으로 하나씩 더블 클릭하며 탐색하는 방식을 추천했다.

이건 단순히 예쁘게 보여주는 문제가 아니다.
분석 속도와 이해의 질을 바꾸는 방식이다.

---

보안 관점에서 왜 유용한가

이 세션이 인상적이었던 이유는
그래프 시각화를 단순 운영 편의성으로만 말하지 않고,
보안 사고 대응과 영향도 분석까지 연결했다는 점이다.

권한 사고나 계정 탈취가 발생했을 때 보안팀이 바로 알고 싶은 건 보통 이런 것이다.

• 공격자가 가진 계정으로 어디까지 이동 가능한가
• 어떤 그룹과 권한이 연결돼 있는가
• 어떤 계정과 역할로 확장 가능한가
• 원래 의도보다 과도한 권한이 부여된 경로는 없는가

발표자는 그래프를 활용하면 이런 영향도 파악이 훨씬 쉬워진다고 설명했다.
특히 “공격자라면 어디까지 갈 수 있지?”를 추적하는 데 유용하다는 말이 인상적이었다.

모의해킹이나 권한 리뷰 관점에서도 마찬가지다.

• 이 서비스는 원래 저 정도 권한이 필요 없는데 왜 이런 권한이 있지?
• 이 그룹은 너무 넓게 퍼져 있지 않나?
• 실제 사용되지 않는 권한이 붙어 있지 않나?

이런 걸 텍스트보다 그래프가 더 잘 드러내준다.

---

EventBridge와 Access Analyzer 연동 아이디어

발표에서는 단순 시각화에서 한 걸음 더 나아가
IAM Access Analyzer와 EventBridge를 연결해 위험 신호를 그래프에 반영하는 아이디어도 언급했다.

즉 구조는 이렇다.

• Access Analyzer가 위험 권한이나 이상 징후를 감지
• EventBridge가 이벤트를 받음
• 그래프 상에서 해당 노드나 관계를 강조

이 아이디어가 좋은 이유는
그래프가 단순 정적 그림이 아니라 위험도 맥락이 얹힌 운영 화면으로 발전할 수 있기 때문이다.

다만 발표에서는 구현상의 제약도 솔직히 언급했다.

• external 관련 코드는 동작하지 않는 부분이 있음
• internal 분석은 가능하지만 유료
• unused access는 시간 기반 검증이 필요해서 테스트가 번거로움

즉, 방향성은 좋지만 아직은 실험적 요소가 남아 있다는 점도 같이 보여줬다.

---

이 구조의 분명한 한계

이 세션이 좋았던 이유 중 하나는
장점만 말하지 않고 한계도 아주 명확하게 드러냈다는 점이다.

1. 엣지 생성이 Lambda의 하드코딩 로직에 의존한다

가장 큰 한계는 여기였다.
엣지는 Lambda 함수가 미리 알고 있는 패턴만 만들 수 있다.
즉, Lambda가 모르는 관계는 그래프에 안 나온다.
발표에서도 이 부분을 구조적 한계로 인정했다.

이 말은 곧, 그래프가 있어도 완전한 진실의 지도는 아닐 수 있다는 뜻이다.

2. 비용이 만만치 않다

Neptune, SageMaker, Lambda, Step Functions, CloudFormation이 모두 붙는다.
특히 Neptune은 떠 있는 동안 계속 비용이 나가고, SageMaker도 인스턴스 비용이 발생한다.
발표자는 이 점을 꽤 강하게 강조했다.

3. 실시간성에 약하다

Q&A에서도 나왔지만, 현재 구조는 주기적으로 그래프를 다시 만들고,
기존 그래프를 지웠다가 다시 적재하는 방식에 가깝다.
게다가 Notebook 재생성까지 겹치면 실시간 운영에는 불리하다.
발표자도 이 부분은 구조 개선이 필요하다고 답했다.

4. 오픈소스 샘플이 그대로 잘 돌아가진 않는다

발표자는 직접 테스트하면서 오류가 많았다고 했고,
그대로 실행하면 쉽게 되지 않는다고 솔직히 말했다.

이런 현실적인 언급 덕분에 오히려 발표 신뢰도가 더 높아졌다.

---

AI로 한계를 돌파할 수 있을까

후반부에서 개인적으로 가장 흥미로웠던 부분은
엣지 생성 한계를 AI로 보완하려는 아이디어였다.

발표자는 Permission Set 안의 정책을 읽고,
그 정책으로부터 “어떤 리소스에 어떤 액션이 가능한가”를
AI가 해석해서 엣지로 만들어주는 방향을 검토 중이라고 설명했다.

이건 꽤 재미있는 확장 포인트다.

기존 방식:

• 정규식 기반
• 사람이 미리 아는 패턴만 엣지화 가능

확장 방식:

• 정책 문서 자체를 AI가 해석
• 더 유연하게 권한 관계 추출 가능

물론 이 방식도 검증과 오탐 문제가 있을 수 있다.
하지만 적어도 “하드코딩된 엣지 밖은 못 본다”는 한계를 넘는 방향이라는 점에서는 충분히 의미 있어 보였다.

---

발표를 듣고 느낀 핵심 포인트

이번 세션을 듣고 정리한 핵심은 이렇다.

1. 권한 관리는 원래부터 그래프 문제다

사용자-그룹-권한-계정-역할-리소스 연결은 본질적으로 관계형 구조다.
그래서 보안 운영에서는 표보다 그래프가 더 잘 맞는 경우가 많다.

2. 시각화는 단순 장식이 아니라 분석 도구다

사람이 이해하는 속도와 정확도를 높여준다.
특히 권한 리뷰, 영향도 분석, 모의해킹 관점에서 강점이 크다.

3. AWS 네이티브 서비스만으로도 이런 구조를 만들 수 있다

Step Functions, Lambda, DynamoDB, S3, Neptune, SageMaker를 조합해
권한 시각화 파이프라인을 만들 수 있다는 점이 흥미로웠다.

4. 다만 “이대로 쓰기”보다는 “아이디어를 가져가기”가 더 중요하다

발표자도 결국 말하고 싶었던 건
이 아키텍처를 그대로 복제하라는 게 아니라,
그래프로 생각하라는 점이라고 했다.

---

개인적인 후기

이번 세션은 보안 발표이면서도 동시에
데이터 모델링과 운영 가시성 설계에 대한 발표처럼 느껴졌다.

특히 좋았던 점은 현실성이었다.

• 구조는 멋지지만 비용이 든다
• 샘플 코드는 그대로 잘 안 된다
• 실시간성은 부족하다
• 엣지 생성은 완전하지 않다

이런 한계를 숨기지 않고 말해줬다.
그래서 더 실무적이었다.

그리고 발표를 들으면서 가장 크게 남은 메시지는 이것이었다.

권한 정보는 저장보다 “관계로 보여주는 방식”이 더 중요하다.

보안 운영에서는 결국 빠르게 답해야 한다.

• 누구 권한이지?
• 어디까지 연결되지?
• 왜 이런 권한이 붙었지?
• 이 사고가 어디까지 번질 수 있지?

이 질문에 빠르게 답할 수 있게 만드는 도구라면,
그래프 기반 접근은 충분히 시도해볼 가치가 있다.

특히 멀티 계정, Identity Center, 외부 IdP, Permission Set 구조가 복잡해지는 조직이라면
이런 시각화는 단순 편의 기능이 아니라 운영 성숙도를 높이는 장치가 될 수 있겠다는 생각이 들었다.

---

마무리

이번 ARIA-gv 세션은
AWS 권한 구조를 어떻게 더 잘 이해하고 운영할 것인가에 대한 좋은 사례였다.

핵심은 단순하다.

• 권한은 관계다
• 관계는 그래프로 보는 게 강하다
• 그래프는 보안 가시성과 영향도 분석에 도움이 된다
• 다만 현재 구현은 비용, 실시간성, 엣지 생성 완전성에서 보완이 필요하다

그래도 방향성만큼은 분명했다.

IAM Role과 User를 그냥 표로만 보지 말고,
관계의 지도처럼 그려서 보자.

이 한 문장만으로도 이 세션은 충분히 의미 있었다.