WEBVTT

00:00:00.000 --> 00:00:01.460
이런 상황을 상상해보세요.

00:00:01.720 --> 00:00:07.460
애플리케이션을 빌드하는데 서비스 연결을 위한 API 키나 데이터베이스 비밀번호 혹은 스토리지 개정키가 필요합니다.

00:00:07.620 --> 00:00:11.200
그래서 코드에 바로 넣거나 구성 파일 또는 환경 변수에 저장하죠.

00:00:11.420 --> 00:00:16.160
그 코드를 GitHub FC하거나 팀원과 노트북을 공유하기 전까지는 모든 게 잘 작동합니다.

00:00:16.380 --> 00:00:19.040
그런데 그 순간 비밀은 더 이상 비밀이 아니게 됩니다.

00:00:19.400 --> 00:00:22.840
만약 그 코드가 잘못된 손에 넘어가면 시스템 전체가 노출되는 거죠.

00:00:23.060 --> 00:00:25.940
이제 에이저 키 볼트가 바로 그 문제를 해결해줄 도구입니다.

00:00:26.160 --> 00:00:29.500
비밀 정보를 코드에 남기지 않고 안전하게 저장할 수 있는 공간을 제공하거든요.

00:00:29.500 --> 00:00:31.940
하지만 대부분의 사람들이 잘못 알고 있는 점이 있습니다.

00:00:32.100 --> 00:00:34.820
키볼트가 있다고 해서 무조건 안전해지는 건 아닙니다.

00:00:35.040 --> 00:00:38.980
어떻게 설정하고 접근을 제어하며 권한을 부여하는지가 훨씬 중요하죠.

00:00:39.200 --> 00:00:46.720
이번 에피소드가 끝나면 키볼트 위 정체, 저장 가능한 항목, 작동 방식, 그리고 비밀이 노출될 수 있는 가장 큰 실수까지 알게 되실 겁니다.

00:00:47.000 --> 00:00:49.340
전문 용어 없이 쉬운 말로 핵심만 짚어드릴게요.

00:00:49.700 --> 00:00:51.820
그렇다면 에이저 키 볼트란 정확히 무엇일까요?

00:00:52.000 --> 00:00:53.440
에이저 키 볼트란 무엇인가요?

00:00:53.640 --> 00:00:55.040
가장 간단하게 정의해보겠습니다.

00:00:55.440 --> 00:00:58.600
에이저 키 볼트는 여러분의 비밀 정보를 위한 클라우드 기반 디지털 금고입니다.

00:00:58.600 --> 00:01:05.480
에이피아이 키, 데이터베이스 비밀번호, 연결 문자열, 암호화 키, 인증서를 한 곳에 모아 관리하는 마이크로소프트 위 서비스죠.

00:01:05.620 --> 00:01:09.500
에이저 가페치, 가동시간, 보안을 책임짐으로 인프라를 걱정할 필요가 없습니다.

00:01:09.760 --> 00:01:11.140
그저 사용하기만 하면 되죠.

00:01:11.320 --> 00:01:12.840
사무용 건물을 하나 떠올려보세요.

00:01:13.140 --> 00:01:18.220
작업 공간과 회의실, 서류 캐비닛이 있지만 지하 어딘가에는 중요한 것을 보관하는 안전한 금고실이 있습니다.

00:01:18.480 --> 00:01:20.980
마스터 키, 현금, 법적 문서 같은 것들 있죠.

00:01:21.180 --> 00:01:23.140
허가와 인증 없이는 아무도 들어갈 수 없습니다.

00:01:23.140 --> 00:01:25.300
누군가 문을 열 때마다 기록도 남고요.

00:01:25.500 --> 00:01:26.760
그게 바로 키 볼트입니다.

00:01:27.000 --> 00:01:29.740
여러분의 에이저 아키텍처 지하에 있는 안전한 방이죠.

00:01:29.960 --> 00:01:31.780
이제 예전 방식과 비교해볼까요.

00:01:31.980 --> 00:01:37.500
20년 전에는 데이터베이스 비밀번호가 필요하면 구성 파일에 하드코딩하거나 환경 변수에 넣었고,

00:01:38.060 --> 00:01:40.320
심하면 소스 코드에 평문으로 남기기도 했습니다.

00:01:40.620 --> 00:01:43.500
누군가 서버에 접근하면 모든 정보를 가져갈 수 있었죠.

00:01:43.640 --> 00:01:46.600
게다가 비밀번호를 변경해야 하면 모든 곳을 업데이트해야 했습니다.

00:01:46.920 --> 00:01:49.460
모든 구성 파일, 모든 환경, 모든 배포 항목을요.

00:01:49.560 --> 00:01:50.800
정말 악몽 같은 일이었죠.

00:01:50.800 --> 00:01:52.740
키 볼트는 이 모든 것을 바꿔놓습니다.

00:01:52.740 --> 00:01:56.920
코드나 구성 파일에 비밀을 흩뿌려 놓는 대신 중앙의 한 곳에 저장하는 겁니다.

00:01:57.220 --> 00:02:00.180
애플리케이션은 필요할 때만 런타임에 이를 요청하게 되죠.

00:02:00.340 --> 00:02:03.800
모든 것이 중앙 집중화되어 있기 때문에 한 곳에서 비밀값을 교체하면

00:02:03.800 --> 00:02:08.680
이를 사용하는 모든 애플리케이션이 코드 변경이나 재배포 없이 자동으로 새로운 값을 가져옵니다.

00:02:08.860 --> 00:02:12.440
하지만 중요한 점은 키 볼트가 단순히 앱을 위한 비밀번호 관리자가 아니라는 것입니다.

00:02:12.640 --> 00:02:14.040
이는 핵심 보안 서비스입니다.

00:02:14.280 --> 00:02:16.220
모든 에이저 서비스와 통합할 수 있습니다.

00:02:16.220 --> 00:02:22.260
앱 서비스, 펑션스, AKS, 데이터 팩토리, 시냅스, 로직 앱스, 데봅스 파이프라인 모두 키 볼트와 통신하는 방법을 알고 있습니다.

00:02:22.460 --> 00:02:24.960
이것이 여러분의 안전한 클라우드 아키텍처에 중추가 됩니다.

00:02:25.220 --> 00:02:28.720
한 번 제대로 설정해두면 자격 증명 관리에 대해 더 이상 고민할 필요가 없습니다.

00:02:29.000 --> 00:02:30.300
무엇을 저장할 수 있을까요?

00:02:30.500 --> 00:02:34.180
이제 키 볼트가 무엇인지 알아드니 실제로 그 안에 무엇을 넣을 수 있는지 알아보겠습니다.

00:02:34.440 --> 00:02:38.360
세 가지 주요 범주인 비밀, 시크릿즈, 키, 키즈, 인증서, 서티피케이티즈가 있습니다.

00:02:38.640 --> 00:02:42.320
각각의 역할이 다름으로 차이를 이해해야 키 볼트를 올바르게 사용할 수 있습니다.

00:02:42.320 --> 00:02:46.380
비밀부터 시작해보겠습니다. 이것은 사람들이 가장 흔히 저장하는 항목입니다.

00:02:46.520 --> 00:02:54.120
비밀은 연결 문자열, API 키, 데이터베이스 비밀번호, 스토리지 계정 키 등 앱이 다른 서비스와 통신하는 데 필요한 일상적인 자격 증명입니다.

00:02:54.300 --> 00:02:57.460
이를 코드나 구성 파일에 넣는 대신 키 볼트에 저장합니다.

00:02:57.720 --> 00:03:01.080
앱이 런타임에 이를 가져오므로 누구도 일반 텍스트로 된 값을 볼 수 없습니다.

00:03:01.360 --> 00:03:04.040
디지털 서류 보관함에 잠긴 서랍이라고 생각하시면 됩니다.

00:03:04.340 --> 00:03:05.200
다음은 키입니다.

00:03:05.420 --> 00:03:08.060
이는 저장 데이터, 데이터 앳 네스트를 위한 암호화 키입니다.

00:03:08.060 --> 00:03:14.400
에이저 스토리지, SQL 데이터베이스, 가상 머신 디스크 암호화의 고객 관리형 키를 사용하는 경우 해당 키를 키 볼트에 저장할 수 있습니다.

00:03:14.560 --> 00:03:17.520
이를 통해 누가 언제 키를 사용할 수 있는지 완전히 제어할 수 있습니다.

00:03:17.720 --> 00:03:22.280
규정 준수를 위해 하드웨어 기반 키가 필요하다면 프리미엄 계층의 hsm 보호 기능을 사용할 수 있습니다.

00:03:22.520 --> 00:03:23.620
다음은 인증서입니다.

00:03:23.860 --> 00:03:27.760
웹앱, API, 내부 서비스를 위한 tls 및 ssl 인증서입니다.

00:03:27.960 --> 00:03:32.140
키 볼트는 이를 저장하고 수명 주기를 관리하며 만료 임박 시 자동 갱신까지 수행합니다.

00:03:32.140 --> 00:03:36.780
일요일 새벽 3시에 인증서가 만료되어 곤란을 겪어본 사람이라면 누구나 구세주처럼 느낄 기능입니다.

00:03:36.920 --> 00:03:38.340
실제 사례를 하나 들어보겠습니다.

00:03:38.700 --> 00:03:43.100
데이터베이스 연결 문자열과 타사 서비스용 API 키가 필요한 웹앱이 있다고 가정해봅시다.

00:03:43.260 --> 00:03:46.500
과거 방식이라면 두 항목 모두 앱 설정 json 파일에 넣었을 것입니다.

00:03:46.720 --> 00:03:51.920
만약 해당 파일이 리포지토리에 올라가면 코드에 접근 권한이 있는 사람은 누구나 데이터베이스 자격 증명을 볼 수 있습니다.

00:03:52.140 --> 00:03:54.620
키 볼트를 사용하면 두 값을 모두 비밀로 저장합니다.

00:03:54.840 --> 00:03:57.700
앱이 시작될 때 이를 가져오므로 소스 코드에는 절대 나타나지 않습니다.

00:03:57.700 --> 00:04:01.220
데이터베이스 비밀번호를 교체해야 하나요? 키 볼트에서 업데이트하세요.

00:04:01.360 --> 00:04:03.900
앱은 다음 재시작 시 자동으로 새로운 값을 가져옵니다.

00:04:04.060 --> 00:04:05.820
코드 변경도 재배포도 필요 없습니다.

00:04:06.120 --> 00:04:08.620
버전 관리가 기본으로 포함되어 있다는 점을 의외로 모르는 분들이 많습니다.

00:04:08.800 --> 00:04:11.420
보안 비밀을 업데이트해도 키 볼트는 이전 값을 덮어 쓰지 않습니다.

00:04:11.600 --> 00:04:12.880
대신 새 버전을 생성합니다.

00:04:13.120 --> 00:04:16.200
이전 버전은 보존됨으로 문제가 발생하면 언제든 되돌릴 수 있습니다.

00:04:16.440 --> 00:04:18.320
이는 사고 발생 시 매우 유용합니다.

00:04:18.560 --> 00:04:22.360
이전 값을 기억할 필요 없이 이전 보안 비밀로 빠르게 복원할 수 있습니다.

00:04:22.360 --> 00:04:27.120
보안 비밀, 키, 인증서 3가지 유형 모두 하나의 자격 증명 모음에 저장할 수 있습니다.

00:04:27.320 --> 00:04:29.700
하지만 환경별로 분리하는 것이 가장 좋습니다.

00:04:29.900 --> 00:04:33.540
개발용, 테스트용, 운영용 자격 증명 모음을 각각 따로 만드세요.

00:04:33.740 --> 00:04:36.800
이렇게 하면 실수로 운영 보안 비밀을 개발 환경에서 사용하는 것을 방지하고

00:04:36.800 --> 00:04:39.940
하나의 자격 증명 모음이 손상되더라도 피해 범위를 제한할 수 있습니다.

00:04:40.140 --> 00:04:42.300
하지만 보안 비밀을 저장하는 것이 전부는 아닙니다.

00:04:42.480 --> 00:04:44.760
진짜 중요한 문제는 누가 그 데이터에 접근할 수 있느냐는 것입니다.

00:04:44.960 --> 00:04:46.620
액세스 제어의 작동 방식에 대해 알아봅시다.

00:04:46.800 --> 00:04:48.500
이제 누가 접근할 수 있는지 이야기해보겠습니다.

00:04:48.500 --> 00:04:51.480
키볼트에는 내부 데이터에 대한 액세스를 제어하는 두 가지 방법이 있으며

00:04:51.480 --> 00:04:53.180
선택에 따라 큰 차이가 발생합니다.

00:04:53.280 --> 00:04:55.380
첫 번째 모델은 기존 액세스 정책입니다.

00:04:55.580 --> 00:04:56.760
이는 구식 방식입니다.

00:04:57.000 --> 00:04:58.960
자격 증명 모음에 직접 정책을 만들고

00:04:58.960 --> 00:05:04.100
특정 사용자 나 그룹의 보안 비밀, 키, 인증서 같은 특정 데이터 유형에 대한 권한을 할당합니다.

00:05:04.340 --> 00:05:07.360
문제는 이 정책들이 자격 증명 모음에 직접 연결되어 있다는 점입니다.

00:05:07.560 --> 00:05:10.680
자격 증명 모음이 여러 개라면 각 모음의 정책을 별도로 관리해야 합니다.

00:05:10.880 --> 00:05:12.100
확장성이 좋지 않습니다.

00:05:12.520 --> 00:05:14.460
마이크로소프트는 보안 문제가 알려져 있으므로

00:05:14.460 --> 00:05:16.380
이제 이 정책의 사용을 권장하지 않습니다.

00:05:16.380 --> 00:05:18.920
이 방식은 권한 있는 아이디 관리를 지원하지 않으며

00:05:18.920 --> 00:05:21.240
예상치 못한 권한 상승 경로를 만들 수 있습니다.

00:05:21.420 --> 00:05:24.700
두 번째 모델은 에이저 RBAC, 즉 역할 기반 액세스 제어입니다.

00:05:24.920 --> 00:05:26.120
이것이 최신 방식입니다.

00:05:26.360 --> 00:05:27.760
엔트라 아이디 아이디를 사용하며

00:05:27.760 --> 00:05:30.600
에이저 위 다른 모든 권한 관리 방식과 일관성을 유지합니다.

00:05:30.820 --> 00:05:33.820
스토리지 계정이나 가상 머신에 액세스 권한을 부여하는 방법을 이미 알고 있다면

00:05:33.820 --> 00:05:36.260
키볼트에 권한을 부여하는 방법도 이미 아는 셈입니다.

00:05:36.440 --> 00:05:38.260
동일한 시스템, 동일한 패턴입니다.

00:05:38.460 --> 00:05:40.800
여기서 가장 중요한 원칙은 최소 권한의 원칙입니다.

00:05:40.800 --> 00:05:42.940
꼭 필요한 최소한의 액세스 권한만 부여하고

00:05:42.940 --> 00:05:44.140
그 이상은 주지 마세요.

00:05:44.280 --> 00:05:45.920
보안 비밀을 읽기만 하면 되는 사람에게

00:05:45.920 --> 00:05:47.780
생성이나 삭제 권한을 주지 마십시오.

00:05:47.900 --> 00:05:49.300
인증서만 관리하면 되는 사람에게

00:05:49.300 --> 00:05:51.060
키에 대한 액세스 권한을 주지 마십시오.

00:05:51.180 --> 00:05:52.380
주요 역할들을 살펴보겠습니다.

00:05:52.740 --> 00:05:54.340
먼저 키볼트 읽기 권한자 리더 가 있습니다.

00:05:54.580 --> 00:05:55.860
이는 보안 비밀 목록을 나열할 수는 있지만

00:05:55.860 --> 00:05:56.940
그 값은 읽을 수 없게 합니다.

00:05:57.080 --> 00:05:58.980
키볼트 보안 비밀 사용자 시크리츠 유저 가 있습니다.

00:05:59.220 --> 00:06:00.940
이 권한은 보안 비밀 값을 실제로 읽을 수 있게 해줍니다.

00:06:00.940 --> 00:06:03.360
그리고 키볼트 보안 비밀 관리자 시크리츠 오피서 가 있습니다.

00:06:03.600 --> 00:06:05.940
이 권한은 보안 비밀을 생성, 업데이트, 삭제할 수 있게 합니다.

00:06:06.080 --> 00:06:06.940
패턴이 보이시나요?

00:06:07.180 --> 00:06:08.600
각 역할은 자격증명 모음 자체가 아니라

00:06:08.600 --> 00:06:10.040
그 안에 있는 데이터에 특화되어 있습니다.

00:06:10.300 --> 00:06:12.040
이제 소유자, 기여자, 읽기 권한자와 같은

00:06:12.040 --> 00:06:13.060
광범위한 역할과 비교해보겠습니다.

00:06:13.360 --> 00:06:15.760
이 역할들은 리소스인 자격증명 모음, 볼트에 적용되는 것이지

00:06:15.760 --> 00:06:17.240
그 내부 데이터에 적용되는 것이 아닙니다.

00:06:17.380 --> 00:06:19.100
소유자는 자격증명 모음 전체를 삭제할 수 있습니다.

00:06:19.300 --> 00:06:21.400
기여자는 자격증명 모음 설정을 수정할 수 있습니다.

00:06:21.660 --> 00:06:24.680
하지만 이 역할들만으로는 내부의 비밀 정보에 접근할 수 없습니다.

00:06:24.980 --> 00:06:27.680
그것은 별도의 권한 계층이며 핵심이 되는 부분입니다.

00:06:27.900 --> 00:06:29.720
액세스 제어는 계층형 구조로 되어 있습니다.

00:06:30.020 --> 00:06:32.540
첫 번째 계층인 자격증명 모음 자체에 대한 액세스 권한이 필요하고

00:06:32.540 --> 00:06:35.220
두 번째 계층인 모음 내부 데이터에 대한 액세스 권한이 필요합니다.

00:06:35.380 --> 00:06:36.860
둘 다 별도로 부여되어야 합니다.

00:06:36.860 --> 00:06:39.020
대부분의 초보자는 첫 번째 계층만 생각하고

00:06:39.020 --> 00:06:40.280
두 번째 계층은 잊어버립니다.

00:06:40.480 --> 00:06:41.820
거기서 문제가 시작됩니다.

00:06:42.040 --> 00:06:43.340
가장 흔한 보안 실수죠.

00:06:43.520 --> 00:06:44.460
중요한 점이 있습니다.

00:06:44.700 --> 00:06:47.560
대부분의 사람은 키볼트 기여자 역할을 보고 안전하다고 생각합니다.

00:06:47.720 --> 00:06:51.560
기여자라는 단어를 보고 설정만 관리할 뿐 내부의 비밀은 건드릴 수 없다고 가정합니다.

00:06:51.780 --> 00:06:54.680
실제로 마이크로소프트의 자체 문서도 처음에는 정확히 그렇게 명시했습니다.

00:06:54.920 --> 00:06:57.960
이 역할은 비밀, 키, 인증서에 액세스할 수 없다고 되어 있습니다.

00:06:58.240 --> 00:06:59.860
하지만 사실은 그렇지 않습니다.

00:07:00.080 --> 00:07:01.880
키볼트 기여자 역할이 있는 사용자는

00:07:01.880 --> 00:07:04.240
자격증명 모음의 액세스 정책을 수정할 수 있습니다.

00:07:04.240 --> 00:07:07.760
여전히 기존 레거시, 액세스 정책을 사용하는 자격증명 모음이라면

00:07:07.760 --> 00:07:12.220
이 사용자는 모든 비밀, 키, 인증서에 대한 전체 읽기 권한을 스스로 부여할 수 있습니다.

00:07:12.400 --> 00:07:14.940
특별한 익스플로잇도 패치할 취약점도 필요 없습니다.

00:07:15.220 --> 00:07:17.020
권한이 원래 그렇게 작동하기 때문입니다.

00:07:17.220 --> 00:07:19.900
데이터도위 보안 연구원들이 2024년에 이를 입증했습니다.

00:07:20.180 --> 00:07:23.020
그들은 기여자가 기존 액세스 정책을 사용하는 모든 자격증명 모음에서

00:07:23.020 --> 00:07:25.300
데이터 전체 액세스 권한으로 승격할 수 있음을 보여주었습니다.

00:07:25.720 --> 00:07:27.420
마이크로소프트의 대응은 흥미로웠습니다.

00:07:27.660 --> 00:07:29.100
그들은 이것이 취약점이 아니라고 했는데

00:07:29.100 --> 00:07:31.840
기여자는 액세스 정책을 관리하도록 설계되었기 때문입니다.

00:07:31.840 --> 00:07:34.340
하지만 동시에 해당 역할이 데이터 평면 액세스 권한을

00:07:34.340 --> 00:07:36.600
스스로 부여할 수 있다는 경고 문구를 문서에 명시했습니다.

00:07:36.800 --> 00:07:39.900
결국, 이건 키볼트 자체의 버그가 아니라 구성상이 함정입니다.

00:07:40.080 --> 00:07:43.240
역할 이름이 무해하게 들리기 때문에 숙련된 팀들도 속아 넘어갑니다.

00:07:43.420 --> 00:07:46.660
기여자라는 말은 데이터베이스 비밀번호를 읽을 수 있는 사람처럼 들리지 않지만

00:07:46.660 --> 00:07:47.740
실제로는 가능합니다.

00:07:47.900 --> 00:07:49.280
위험성을 생각해보십시오.

00:07:49.440 --> 00:07:52.820
공격자가 기아의 키볼트에서 기여자 역할이 있는 계정을 탈취한다면

00:07:52.820 --> 00:07:54.860
모음을 강제로 해킹할 필요가 없습니다.

00:07:55.140 --> 00:07:56.560
암호를 해독할 필요도 없습니다.

00:07:56.560 --> 00:07:59.740
그저 액세스 정책을 수정하여 스스로 읽기 권한을 부여하고

00:07:59.740 --> 00:08:05.600
저장된 모든 비밀, 연결 문자열, API 키, 인증서 등 모든 것을 조용히 유출할 뿐입니다.

00:08:05.780 --> 00:08:08.240
액세스 정책 변경은 일반적인 관리 활동이므로

00:08:08.240 --> 00:08:09.880
경고가 울리지 않을 수도 있습니다.

00:08:10.120 --> 00:08:11.620
그렇다면 해결책은 무엇일까요?

00:08:11.780 --> 00:08:15.220
첫째, 기존 액세스 정책 대신 데이터 평면 액세스의 에이저 RBAC를 사용하십시오.

00:08:15.340 --> 00:08:18.480
RBAC는 자격증명 모음의 관리 권한과 내부 데이터에 대한 권한을 분리합니다.

00:08:18.660 --> 00:08:22.700
둘째, 반드시 필요한 경우가 아니라면 누구에게도 키자격증명 모음 기여자 역할을 부여하지 마십시오.

00:08:22.700 --> 00:08:26.120
셋째, 이미 해당 역할을 가진 사용자가 있다면 오늘 바로 감사하십시오.

00:08:26.240 --> 00:08:29.580
기여자 역할을 키자격증명 모음 비밀 사용자 나키자격증명 모음 비밀 관리자와 같은

00:08:29.580 --> 00:08:31.060
더 구체적인 역할로 대체하십시오.

00:08:31.060 --> 00:08:35.560
이 문제를 악화시키는 두 번째 실수가 있는데, 바로 모든 비밀을 하나의 자격증명 모음에 넣는 것입니다.

00:08:35.740 --> 00:08:39.800
개발, 테스트, 스테이징, 프로덕션 등 모든 환경과 모든 애플리케이션을 위해

00:08:39.800 --> 00:08:43.360
하나의 자격증명 모음만 사용하다가 해당 모음이 침해되면 모든 것이 노출됩니다.

00:08:43.540 --> 00:08:44.880
이는 반일 장애 지점이 됩니다.

00:08:44.880 --> 00:08:48.940
다중 자격증명 모음 전략에 대해서는 잠시 후 자세히 다루겠지만, 원칙은 간단합니다.

00:08:49.060 --> 00:08:53.260
특히 전체 인프라에 열쇠를 쥐고 있는 바구니라면 모든 달걀을 한 곳에 담지 마십시오.

00:08:53.380 --> 00:08:55.520
관리 아이디, 이것이 바로 업계 표준입니다.

00:08:55.680 --> 00:08:57.340
그렇다면 어떻게 올바르게 구현할 수 있을까요?

00:08:57.340 --> 00:08:59.860
키 자격증명 모음에 액세스하는 가장 좋은 방법에 대해 이야기해보겠습니다.

00:09:00.100 --> 00:09:01.320
근본적인 문제가 하나 있습니다.

00:09:01.600 --> 00:09:04.720
키 자격증명 모음에서 자격증명을 가져오려면 애플리케이션이 스스로 인증해야 하는데,

00:09:05.060 --> 00:09:06.280
인증하려면 자격증명이 필요합니다.

00:09:06.440 --> 00:09:09.380
앱이 자격증명을 얻기 위해 사용하는 자격증명은 어디에 저장할까요?

00:09:09.380 --> 00:09:11.580
닭이 먼저 냐 달걀이 먼저 냐의 문제입니다.

00:09:11.720 --> 00:09:14.900
과거의 해결책은 클라이언트 비밀이 포함된 서비스 주체를 사용하는 것이었지만,

00:09:15.320 --> 00:09:19.440
그 클라이언트 비밀은 구성 파일, 환경 변수 또는 배포 파이프라인 등 어딘가에 존재해야 합니다.

00:09:19.620 --> 00:09:21.400
결국 다시 같은 문제로 돌아오게 됩니다.

00:09:21.640 --> 00:09:23.480
비밀을 단지 다른 곳으로 옮겼을 뿐입니다.

00:09:23.680 --> 00:09:25.500
관리 아이디는 이 문제를 완전히 해결합니다.

00:09:25.720 --> 00:09:26.980
작동 방식은 다음과 같습니다.

00:09:27.300 --> 00:09:31.700
웹앱, 함수, 가상 머신과 같은 에이저 리소스에서 관리 아이디를 활성화하면,

00:09:31.700 --> 00:09:35.220
에이저가 자동으로 엔트라 아이디에 해당 리소스의 아이디를 생성합니다.

00:09:35.440 --> 00:09:37.740
이 아이디는 전적으로 에이저에서 관리합니다.

00:09:37.980 --> 00:09:41.380
생성할 자격증명도, 순환시킬 비밀도, 저장할 항목도 없습니다.

00:09:41.700 --> 00:09:44.460
리소스는 에이저가 인지하는 고유한 아이디를 갖게 될 뿐입니다.

00:09:44.660 --> 00:09:46.300
관리 아이디에는 두 가지 유형이 있습니다.

00:09:46.600 --> 00:09:49.600
시스템 할당관리 아이디는 특정 리소스 하나에 연결됩니다.

00:09:49.800 --> 00:09:52.480
해당 리소스를 삭제하면 아이디도 함께 사라집니다.

00:09:52.660 --> 00:09:55.300
둘은 수명주기를 공유함으로 관리가 간편합니다.

00:09:55.300 --> 00:10:00.180
사용자 할당관리 아이디는 여러 리소스에 할당할 수 있는 독립적인 아이디입니다.

00:10:00.360 --> 00:10:05.400
어떤 리소스와도 수명주기를 공유하지 않으므로 여러 서비스에서 동일한 아이디가 필요할 때 유용합니다.

00:10:05.620 --> 00:10:07.220
실제 적용 모습은 다음과 같습니다.

00:10:07.560 --> 00:10:11.640
데이터베이스 연결 문자열을 키자격증명 모음에서 읽어야 하는 웹앱이 있다고 가정해봅시다.

00:10:11.800 --> 00:10:14.380
웹앱에서 시스템 할당관리 아이디를 활성화합니다.

00:10:14.380 --> 00:10:18.700
그런 다음 자격증명 모음에서 해당 아이디의 키 자격증명 모음 비밀 사용자 역할을 부여합니다.

00:10:18.860 --> 00:10:19.720
이것으로 끊입니다.

00:10:19.920 --> 00:10:23.080
코드 내 연결 문자열 또 구성파일 내 클라이언트 비밀도 필요 없습니다.

00:10:23.380 --> 00:10:28.920
웹앱은 관리 아이디를 사용하여 키볼트에 인증하며 에이저가 내부적으로 모든 자격증명 관리를 처리합니다.

00:10:29.120 --> 00:10:32.640
이는 에이저에서 자격증명이 필요 없는 인증에 가장 가까운 방식입니다.

00:10:32.880 --> 00:10:37.720
가장 흔한 공격 경로인 자격증명 탈출을 제거하기 때문에 보안의 판도를 바꿀 수 있습니다.

00:10:37.980 --> 00:10:41.760
훔칠 자격증명이 없다면 공격자가 손상시킬 대상도 없는 셈입니다.

00:10:41.760 --> 00:10:43.300
실제 사례를 들어보겠습니다.

00:10:43.300 --> 00:10:47.540
시냅스 위 데이터 파이프라인이 스토리지 계정에 액세스해야 한다고 가정해봅시다.

00:10:47.680 --> 00:10:50.800
과거에는 파이프라인 구성에 스토리지 계정키를 저장하곤 했습니다.

00:10:51.100 --> 00:10:54.240
누군가 그 파이프라인에 액세스 할 수 있다면 그들은 바로 그 키를 갖게 되는 것이 없습니다.

00:10:54.500 --> 00:10:57.600
관리 아이디를 사용하면 시냅스 작업 영역에 고유한 아이디가 부여됩니다.

00:10:57.800 --> 00:11:01.580
그 아이디에 스토리지 계정키가 저장된 키볼트에 대한 액세스 권한이 부여됩니다.

00:11:01.800 --> 00:11:05.740
파이프라인은 런타임에 키를 가져와 사용하며 어디에도 키를 저장하지 않습니다.

00:11:05.940 --> 00:11:08.940
코드에 키도 없고 파이프라인 구성에 비밀 정보도 없습니다.

00:11:08.940 --> 00:11:14.400
관리 아이디와 RBA시 및 최소 권한 원칙을 결합하면 모든 에이저 워크로드를 위한 안전한 기반이 마련됩니다.

00:11:14.640 --> 00:11:17.020
애플리케이션이 자격 증명 없이 인증을 수행합니다.

00:11:17.200 --> 00:11:20.460
필요한 것에만 액세스하며 모든 액세스는 기록되고 감사할 수 있습니다.

00:11:20.680 --> 00:11:23.780
이는 거의 모든 시나리오에 대해 마이크로소프트가 권장하는 패턴입니다.

00:11:23.960 --> 00:11:27.400
한 번 사용하기 시작하면 왜 이전에는 다른 방식을 썼는지 위하에 할 것입니다.

00:11:27.580 --> 00:11:28.960
비용 및 다중 볼트 전략

00:11:28.960 --> 00:11:30.580
이제 비용에 대해 이야기해보겠습니다.

00:11:30.960 --> 00:11:32.740
이 부분에서 대부분의 사람들이 놀라곤 합니다.

00:11:32.940 --> 00:11:34.920
에이저 키 볼트는 실제로 비용이 얼마나 들까요?

00:11:35.100 --> 00:11:36.240
가격 모델은 간단합니다.

00:11:36.240 --> 00:11:37.760
비밀 항목 당 저장 비용은 없습니다.

00:11:38.080 --> 00:11:40.280
저장하는 각 암호나 api 키에 대해 비용을 지불하지 않습니다.

00:11:40.460 --> 00:11:42.120
대신 작업 단위로 요금이 부과됩니다.

00:11:42.300 --> 00:11:44.860
표준계층의 경우 만 번이 작업당 약 3센트입니다.

00:11:45.080 --> 00:11:47.540
비밀 항목 가져오기 호출 한 번이 한 번이 작업으로 간주됩니다.

00:11:47.740 --> 00:11:50.440
비밀 항목을 생성하거나 볼트 내 항목을 나열하는 작업도 마찬가지입니다.

00:11:50.620 --> 00:11:53.640
일반적인 중소형 애플리케이션의 경우 한 달에 몇 센트 정도면 충분합니다.

00:11:53.840 --> 00:11:55.180
말 그대로 몇 센트 수준이죠.

00:11:55.440 --> 00:11:57.720
aws 시크릿 매니저와 비교해보십시오.

00:11:57.880 --> 00:12:02.020
aws는 비밀 항목 당 월 40센트의 저장 비용을 부과하며 api 호출에 대한 추가 요금도 발생합니다.

00:12:02.180 --> 00:12:05.500
100개의 비밀 항목이 있다면 하나도 읽기 전에 이미 한 달에 40달러가 나가는 셈입니다.

00:12:05.680 --> 00:12:09.500
에이저 키 볼트를 사용하면 100개의 비밀 항목을 적당히 사용할 때 약 15센트 정도가 듭니다.

00:12:09.660 --> 00:12:11.660
규모가 커질 수록이 차이는 빠르게 벌어집니다.

00:12:11.840 --> 00:12:13.140
물론 프리미엄 계층도 있습니다.

00:12:13.440 --> 00:12:17.560
이 계층은 최고 수준의 암호화 보증이 필요한 워크로드를 위해 hsm 기반 키를 제공합니다.

00:12:17.560 --> 00:12:21.200
금융 거래, 의료 데이터, 정보 시스템 등을 예로 들 수 있습니다.

00:12:21.420 --> 00:12:28.300
작업당 비용은 더 높아서 고급 키 유형의 경우 만 번이 작업당 약 15센트이며 hsm 키당 월별 요금이 추가됩니다.

00:12:28.520 --> 00:12:31.800
하지만 대부분의 애플리케이션에는 표준 계층만으로도 차고 넘칩니다.

00:12:32.080 --> 00:12:34.820
사람들이 예상치 못하게 놀라는 비용 관련 사실이 하나 있습니다.

00:12:35.120 --> 00:12:40.260
일반적인 웹앱에서 소수의 보안 비밀과 매달 수천 건의 작업을 수행할 때 키 볼트 비용은 1달러 미만입니다.

00:12:40.500 --> 00:12:42.680
설정하면서 마시는 커피 값이 더 나올 겁니다.

00:12:42.960 --> 00:12:44.820
하지만 비용보다 더 중요한 전략이 있습니다.

00:12:44.820 --> 00:12:46.880
얼마나 많은 자격 증명 모음을 사용하는가 하는 점입니다.

00:12:46.880 --> 00:12:49.280
현명한 접근 방식은 다중 자격 증명 모음 전략을 사용하는 것입니다.

00:12:49.420 --> 00:12:52.840
개발, 테스트, 스테이징, 프로덕션 환경에 각각 별도의 자격 증명 모음을 사용하세요.

00:12:53.000 --> 00:12:54.860
이렇게 하면 가장 흔한 사고를 방지할 수 있습니다.

00:12:55.060 --> 00:12:59.980
테스트 스크립트를 실행하다가 같은 자격 증명 모음에 있던 연결 문자열 때문에 실수로 프로덕션 데이터베이스를 읽는 경우죠.

00:13:00.120 --> 00:13:02.600
환경을 분리하면 그런 실수는 불가능해집니다.

00:13:02.760 --> 00:13:05.480
비즈니스 단위나 규정 준수 영역별로도 분리해야 합니다.

00:13:05.720 --> 00:13:09.180
결제 카드 데이터를 다룬다면 해당 보안 비밀은 별도의 자격 증명 모음에 보관하세요.

00:13:09.180 --> 00:13:12.720
일반 비즈니스 워크로드는 다른 곳에, 의료 데이터는 또 다른 곳에 보관하는 식입니다.

00:13:12.860 --> 00:13:15.800
이는 까다롭게 굴려는 것이 아니라 피해 범위를 제한하기 위한 것입니다.

00:13:15.960 --> 00:13:19.200
하나의 자격 증명 모음이 손상되더라도 해당 모음의 보안 비밀만 노출됩니다.

00:13:19.420 --> 00:13:21.180
나머지 인프라는 안전하게 유지됩니다.

00:13:21.380 --> 00:13:23.760
그리고 항상 활성화해야 할 두 가지 기본 안전장치가 있습니다.

00:13:24.040 --> 00:13:27.580
소프트 삭제는 누군가 보안 비밀을 삭제해도 연구적으로 사라지지 않는다는 의미입니다.

00:13:27.760 --> 00:13:31.800
보안 비밀은 최대 90일까지 선택한 보존 기간 동안 복구 가능한 상태가 됩니다.

00:13:32.120 --> 00:13:34.180
제거 보호는 여기서 한 걸음 더 나아갑니다.

00:13:34.180 --> 00:13:38.360
보존 기간이 만료되기 전까지는 누구도 자격 증명 모음이나 그 내용을 연구적으로 삭제할 수 없습니다.

00:13:38.600 --> 00:13:42.820
이 두 가지 기능을 함께 사용하면 보안팀을 방짬 설치게 하는 예기치 않은 데이터 손실을 방지할 수 있습니다.

00:13:43.000 --> 00:13:44.400
모든 것이 연결되는 방식입니다.

00:13:44.600 --> 00:13:47.020
이 모든 것을 종합하여 각 요소가 어떻게 맞물리는지 살펴보겠습니다.

00:13:47.260 --> 00:13:48.920
키볼트는 고립된 섬이 아닙니다.

00:13:49.100 --> 00:13:51.840
에이저 아키텍처 내 보안 비밀을 위한 중추 신경계와 같습니다.

00:13:52.200 --> 00:13:55.200
전체 시스템의 흐름을 이해하면 모든 것이 자연스럽게 연결됩니다.

00:13:55.440 --> 00:13:58.120
애플리케이션이 보안 비밀을 필요로 할 때 어떤 일이 일어나는지 보겠습니다.

00:13:58.420 --> 00:14:00.820
애플리케이션은 관리 아이디를 사용하여 요청합니다.

00:14:01.020 --> 00:14:03.460
해당 아이디는 이미 엔트라 아이디에 등록되어 있습니다.

00:14:03.800 --> 00:14:07.540
리소스에서 관리 아이디를 활성화하면 에이저가 자동으로 생성합니다.

00:14:07.800 --> 00:14:12.140
엔트라 아이디는 해당 아이디가 유효한지 검증한 후 키볼트로 요청을 전달합니다.

00:14:12.380 --> 00:14:14.960
키볼트는 할당한 RBAC 권한을 확인합니다.

00:14:15.180 --> 00:14:19.040
아이디에 키볼트 보안 비밀 사용자와 같은 올바른 역할이 있다면 보안 비밀이 반환됩니다.

00:14:19.220 --> 00:14:20.960
이 모든 과정은 밀리초 단위로 이루어집니다.

00:14:21.140 --> 00:14:22.940
애플리케이션은 자격 증명을 직접 확인하지 않습니다.

00:14:23.120 --> 00:14:24.440
비밀번호를 저장하지도 않습니다.

00:14:24.440 --> 00:14:25.860
필요한 값만 가져올 뿐입니다.

00:14:26.060 --> 00:14:28.640
이제 얼마나 많은 에이저 서비스가 여기에 연결될 수 있는지 생각해보세요.

00:14:28.820 --> 00:14:32.280
앱 서비스, 펑션스, AKS, 데이터 팩토리, 시냅스, 로직 앱스,

00:14:32.540 --> 00:14:34.680
DevOps 파이프라인즈 모두 키볼트와 통신하는 방법을 알고 있습니다.

00:14:34.860 --> 00:14:38.860
웹 앱을 구성하여 애플리케이션 설정에서 보안 비밀을 직접 참조하게 할 수 있습니다.

00:14:39.080 --> 00:14:43.660
데이터 팩토리 파이프라인이 런타임의 키볼트에서 스토리지 계정 키를 가져오도록 설정할 수도 있습니다.

00:14:43.880 --> 00:14:48.260
키볼트 CSI 드라이버를 사용하여 키번의 클러스터가 비밀을 가져오도록 구성할 수 있습니다.

00:14:48.260 --> 00:14:54.480
모든 서비스는 동일한 ID 시스템, 동일한 RBAC 역할, 동일한 감사로깅을 사용하여 동일한 방식으로 통합됩니다.

00:14:54.660 --> 00:14:56.760
CI, CD 패턴은 특히 강력합니다.

00:14:57.020 --> 00:14:59.940
파이프라인은 배포 시점에 키볼트에서 비밀을 가져옵니다.

00:15:00.100 --> 00:15:02.900
파이프라인 변수 나 리포지토리 비밀에 저장하지 않습니다.

00:15:03.100 --> 00:15:06.520
데이터베이스 비밀번호를 교체해야 하는 경우 키볼트에서 업데이트하면 됩니다.

00:15:06.780 --> 00:15:09.720
다음에 파이프라인이 실행될 때 자동으로 새로운 값을 가져옵니다.

00:15:09.900 --> 00:15:12.560
파이프라인 변경도, 코드 수정도, 재배포도 필요 없습니다.

00:15:12.840 --> 00:15:14.860
이 모든 것을 가능하게 하는 핵심은 바로 이것입니다.

00:15:14.860 --> 00:15:19.460
관리 ID와 RBAC으로 키볼트를 설정하면 자격증명 관리에 대해 더 이상 고민할 필요가 없습니다.

00:15:19.820 --> 00:15:21.320
애플리케이션은 그대로 작동합니다.

00:15:21.520 --> 00:15:23.140
비밀은 아무도 모르게 교체됩니다.

00:15:23.380 --> 00:15:25.580
인증서는 한방중에 비상사태 없이 갱신됩니다.

00:15:25.780 --> 00:15:27.760
시스템이 백그라운드에서의 모든 것을 처리합니다.

00:15:27.980 --> 00:15:29.620
이것이 바로 중요한 보안태세입니다.

00:15:29.880 --> 00:15:31.900
네트워크가 아닌 ID가 경계가 됩니다.

00:15:32.220 --> 00:15:35.020
누군가 가상 네트워크 내부에 있든 외부에 있든 상관없습니다.

00:15:35.240 --> 00:15:38.540
중요한 것은 적절한 권한을 가진 유효한 ID를 보유했는지 여부입니다.

00:15:38.740 --> 00:15:40.680
키볼트는 설계상 이를 강제합니다.

00:15:40.680 --> 00:15:46.060
모든 액세스 요청은 요청 출처와 관계없이 엔트라 ID 인증 및 RBAC 권한 부여를 거칩니다.

00:15:46.320 --> 00:15:47.660
그리고 모든 것이 기록됩니다.

00:15:47.880 --> 00:15:50.380
모든 비밀 읽기, 모든 키 작업, 모든 인증서 검색이 기록됩니다.

00:15:50.560 --> 00:15:52.440
누가 언제 무엇에 액세스했는지 확인할 수 있습니다.

00:15:52.660 --> 00:15:55.160
의심스러운 점이 있으면 조사할 데이터가 확보되어 있습니다.

00:15:55.460 --> 00:15:59.360
이는 규정 준수, 사고 대응, 그리고 환경 내 상황 파악을 위해 매우 중요합니다.

00:15:59.560 --> 00:16:01.220
그것이 바로 이 시스템의 장점입니다.

00:16:01.420 --> 00:16:06.360
키볼트, 엔트라 ID, RBAC 및 관리 ID는 통합보안 프레임 워크로서 함께 작동합니다.

00:16:06.560 --> 00:16:08.300
각 구성 요소는 서로를 강화합니다.

00:16:08.300 --> 00:16:15.280
모두 올바르게 설정되면 직접 구축하는 것보다 훨씬 더 안전하고 운영하기 간단한 자격증명 관리 시스템을 갖게 됩니다.

00:16:15.520 --> 00:16:17.060
실천 가능한 핵심 내용입니다.

00:16:17.280 --> 00:16:19.220
그렇다면 지금 당장 무엇을 해야 할까요?

00:16:19.380 --> 00:16:20.920
이 지식을 행동으로 옮겨봅시다.

00:16:21.140 --> 00:16:23.040
이번 주에 바로 실행할 수 있는 사항들입니다.

00:16:23.260 --> 00:16:24.580
권한 모델부터 시작하세요.

00:16:24.820 --> 00:16:27.460
포털에서 키볼트를 열고 액세스 구성을 확인해보세요.

00:16:27.760 --> 00:16:30.740
자격증명 모음 액세스 정책이 보인다면 그것은 구식 방식입니다.

00:16:30.940 --> 00:16:33.360
대신 에이저 역할 기반 액세스 제어를 사용해야 합니다.

00:16:33.720 --> 00:16:35.000
마이그레이션은 간단합니다.

00:16:35.000 --> 00:16:39.700
권한 모델을 전환하고 기존의 액세스 정책을 가졌던 사람들에게 rbac 역할을 할당하세요.

00:16:39.860 --> 00:16:40.920
오늘 바로 실행하세요.

00:16:41.220 --> 00:16:45.040
마이크로소프트가 권장하는 방식이며 우리가 논의한 연구 결과가 그 이유를 정확히 보여줍니다.

00:16:45.220 --> 00:16:48.080
다음으로 키볼트 기여자 역할을 가진 계정을 감사하세요.

00:16:48.280 --> 00:16:51.440
볼트 위 iam 블레이드를 열어 누가 기여자 액세스 권한을 가지고 있는지 살펴보세요.

00:16:51.660 --> 00:16:53.940
해당 역할을 가진 모든 사람은 파당한 이유를 가지고 있어야 합니다.

00:16:54.100 --> 00:16:55.500
대부분의 경우 그렇지 않습니다.

00:16:55.720 --> 00:16:58.060
기여자 컨트리뷰터 역할을 더 구체적인 것으로 바꾸세요.

00:16:58.200 --> 00:17:01.060
비밀값을 읽기만 하면 된다면 키볼트 비밀 사용자 역할을 부여하세요.

00:17:05.000 --> 00:17:06.980
권한 상승 경로를 완전히 차단하는 것입니다.

00:17:07.120 --> 00:17:09.160
다음으로 관리 아이디를 활용하세요.

00:17:09.340 --> 00:17:12.640
키볼트에 액세스해야 하는 모든 에이저 서비스는 이를 사용해야 합니다.

00:17:12.820 --> 00:17:20.280
웹앱, 함수, 데이터 팩토리 또는 가상 머신이 여전히 클라이언트 암호가 포함된 서비스 주체를 사용 중이 라면 관리 아이디로 전환하세요.

00:17:20.500 --> 00:17:24.200
더 간단하고 안전하며 앞서 다룬 닭과 달걀 문제를 해결해줍니다.

00:17:24.420 --> 00:17:27.320
에이저가 백그라운드에서 자격증명 관리를 대신 처리해줍니다.

00:17:27.520 --> 00:17:31.000
한 가지 더 모든 자격증명 모음에서 일시 삭제 및 제거보호를 활성화하세요.

00:17:31.000 --> 00:17:35.000
새 자격증명 모음은 일시 삭제가 기본적으로 켜져있지만 제거보호는 그렇지 않습니다.

00:17:35.120 --> 00:17:35.820
이를 켜세요.

00:17:36.000 --> 00:17:40.380
이 설정은 보존기간 동안 누구도 자격증명 모음이나 그 내용을 연구적으로 삭제하지 못하게 합니다.

00:17:40.600 --> 00:17:43.220
이미 여러 팀리의 기능 덕분에 치명적인 실수를 피했습니다.

00:17:43.540 --> 00:17:44.700
이제 실천할 시간입니다.

00:17:44.940 --> 00:17:46.860
현재의 비밀관리 방식을 점검해보세요.

00:17:47.100 --> 00:17:51.000
구성 파일, 환경 변수 또는 코드에 하드코딩되어 남아있는 비밀값을 하나 찾으세요.

00:17:51.200 --> 00:17:52.660
이번 주에 키볼트로 옮기세요.

00:17:52.860 --> 00:17:53.540
딱 하나만요.

00:17:53.720 --> 00:17:55.840
얼마나 간단한지 확인하고 나면 나머지도 옮기고 싶어질 겁니다.

00:17:56.060 --> 00:17:57.500
보안은 한 번 설정으로 끝나는 게 아닙니다.

00:18:01.000 --> 00:18:02.760
도구는 이미 준비되어 있습니다.

00:18:03.000 --> 00:18:04.140
패턴은 이미 검증되었습니다.

00:18:04.420 --> 00:18:06.160
이제 이를 구현하는 것은 여러분의 목입니다.

00:18:06.340 --> 00:18:07.300
그것이 시스템입니다.

00:18:07.480 --> 00:18:11.260
키볼트는 여러분의 디지털 금고이지만 그 주변에 설정한 액세스 제어만큼만 안전합니다.

00:18:11.440 --> 00:18:13.100
제가 설명한 감사부터 시작하세요.

00:18:13.280 --> 00:18:14.440
권한 모델을 확인하세요.

00:18:14.660 --> 00:18:18.040
기여자 할당을 검토하고 이번 주에 비밀값 하나를 자격증명 모음으로 옮기세요.

00:18:18.220 --> 00:18:20.580
더 많은 클라우드 보안 정보를 쉽게 확인하려면 구독하시고

00:18:20.580 --> 00:18:23.880
여전히 구성 파일에 비밀값을 저장하는 분들에게 이 영상을 공유해주세요.