이런 상황을 상상해보세요.애플리케이션을 빌드하는데 서비스 연결을 위한 API 키나 데이터베이스 비밀번호 혹은 스토리지 개정키가 필요합니다.그래서 코드에 바로 넣거나 구성 파일 또는 환경 변수에 저장하죠.그 코드를 GitHub FC하거나 팀원과 노트북을 공유하기 전까지는 모든 게 잘 작동합니다.그런데 그 순간 비밀은 더 이상 비밀이 아니게 됩니다.만약 그 코드가 잘못된 손에 넘어가면 시스템 전체가 노출되는 거죠.이제 에이저 키 볼트가 바로 그 문제를 해결해줄 도구입니다.비밀 정보를 코드에 남기지 않고 안전하게 저장할 수 있는 공간을 제공하거든요.하지만 대부분의 사람들이 잘못 알고 있는 점이 있습니다.키볼트가 있다고 해서 무조건 안전해지는 건 아닙니다.어떻게 설정하고 접근을 제어하며 권한을 부여하는지가 훨씬 중요하죠.이번 에피소드가 끝나면 키볼트 위 정체, 저장 가능한 항목, 작동 방식, 그리고 비밀이 노출될 수 있는 가장 큰 실수까지 알게 되실 겁니다.전문 용어 없이 쉬운 말로 핵심만 짚어드릴게요.그렇다면 에이저 키 볼트란 정확히 무엇일까요?에이저 키 볼트란 무엇인가요?가장 간단하게 정의해보겠습니다.에이저 키 볼트는 여러분의 비밀 정보를 위한 클라우드 기반 디지털 금고입니다.에이피아이 키, 데이터베이스 비밀번호, 연결 문자열, 암호화 키, 인증서를 한 곳에 모아 관리하는 마이크로소프트 위 서비스죠.에이저 가페치, 가동시간, 보안을 책임짐으로 인프라를 걱정할 필요가 없습니다.그저 사용하기만 하면 되죠.사무용 건물을 하나 떠올려보세요.작업 공간과 회의실, 서류 캐비닛이 있지만 지하 어딘가에는 중요한 것을 보관하는 안전한 금고실이 있습니다.마스터 키, 현금, 법적 문서 같은 것들 있죠.허가와 인증 없이는 아무도 들어갈 수 없습니다.누군가 문을 열 때마다 기록도 남고요.그게 바로 키 볼트입니다.

여러분의 에이저 아키텍처 지하에 있는 안전한 방이죠.이제 예전 방식과 비교해볼까요. 20년 전에는 데이터베이스 비밀번호가 필요하면 구성 파일에 하드코딩하거나 환경 변수에 넣었고,심하면 소스 코드에 평문으로 남기기도 했습니다.누군가 서버에 접근하면 모든 정보를 가져갈 수 있었죠.게다가 비밀번호를 변경해야 하면 모든 곳을 업데이트해야 했습니다.모든 구성 파일, 모든 환경, 모든 배포 항목을요.정말 악몽 같은 일이었죠.키 볼트는 이 모든 것을 바꿔놓습니다.코드나 구성 파일에 비밀을 흩뿌려 놓는 대신 중앙의 한 곳에 저장하는 겁니다.애플리케이션은 필요할 때만 런타임에 이를 요청하게 되죠.모든 것이 중앙 집중화되어 있기 때문에 한 곳에서 비밀값을 교체하면이를 사용하는 모든 애플리케이션이 코드 변경이나 재배포 없이 자동으로 새로운 값을 가져옵니다.하지만 중요한 점은 키 볼트가 단순히 앱을 위한 비밀번호 관리자가 아니라는 것입니다.이는 핵심 보안 서비스입니다.모든 에이저 서비스와 통합할 수 있습니다.앱 서비스, 펑션스, AKS, 데이터 팩토리, 시냅스, 로직 앱스, 데봅스 파이프라인 모두 키 볼트와 통신하는 방법을 알고 있습니다.이것이 여러분의 안전한 클라우드 아키텍처에 중추가 됩니다.한 번 제대로 설정해두면 자격 증명 관리에 대해 더 이상 고민할 필요가 없습니다.무엇을 저장할 수 있을까요?이제 키 볼트가 무엇인지 알아드니 실제로 그 안에 무엇을 넣을 수 있는지 알아보겠습니다.세 가지 주요 범주인 비밀, 시크릿즈, 키, 키즈, 인증서, 서티피케이티즈가 있습니다.각각의 역할이 다름으로 차이를 이해해야 키 볼트를 올바르게 사용할 수 있습니다.비밀부터 시작해보겠습니다. 이것은 사람들이 가장 흔히 저장하는 항목입니다.비밀은 연결 문자열, API 키, 데이터베이스 비밀번호, 스토리지 계정 키 등 앱이 다른 서비스와 통신하는 데 필요한 일상적인 자격 증명입니다.

이를 코드나 구성 파일에 넣는 대신 키 볼트에 저장합니다.앱이 런타임에 이를 가져오므로 누구도 일반 텍스트로 된 값을 볼 수 없습니다.디지털 서류 보관함에 잠긴 서랍이라고 생각하시면 됩니다.다음은 키입니다.이는 저장 데이터, 데이터 앳 네스트를 위한 암호화 키입니다.에이저 스토리지, SQL 데이터베이스, 가상 머신 디스크 암호화의 고객 관리형 키를 사용하는 경우 해당 키를 키 볼트에 저장할 수 있습니다.이를 통해 누가 언제 키를 사용할 수 있는지 완전히 제어할 수 있습니다.규정 준수를 위해 하드웨어 기반 키가 필요하다면 프리미엄 계층의 hsm 보호 기능을 사용할 수 있습니다.다음은 인증서입니다.웹앱, API, 내부 서비스를 위한 tls 및 ssl 인증서입니다.키 볼트는 이를 저장하고 수명 주기를 관리하며 만료 임박 시 자동 갱신까지 수행합니다.일요일 새벽 3시에 인증서가 만료되어 곤란을 겪어본 사람이라면 누구나 구세주처럼 느낄 기능입니다.실제 사례를 하나 들어보겠습니다.데이터베이스 연결 문자열과 타사 서비스용 API 키가 필요한 웹앱이 있다고 가정해봅시다.과거 방식이라면 두 항목 모두 앱 설정 json 파일에 넣었을 것입니다.만약 해당 파일이 리포지토리에 올라가면 코드에 접근 권한이 있는 사람은 누구나 데이터베이스 자격 증명을 볼 수 있습니다.키 볼트를 사용하면 두 값을 모두 비밀로 저장합니다.앱이 시작될 때 이를 가져오므로 소스 코드에는 절대 나타나지 않습니다.데이터베이스 비밀번호를 교체해야 하나요? 키 볼트에서 업데이트하세요.앱은 다음 재시작 시 자동으로 새로운 값을 가져옵니다.코드 변경도 재배포도 필요 없습니다.버전 관리가 기본으로 포함되어 있다는 점을 의외로 모르는 분들이 많습니다.보안 비밀을 업데이트해도 키 볼트는 이전 값을 덮어 쓰지 않습니다.대신 새 버전을 생성합니다.이전 버전은 보존됨으로 문제가 발생하면 언제든 되돌릴 수 있습니다.

이는 사고 발생 시 매우 유용합니다.이전 값을 기억할 필요 없이 이전 보안 비밀로 빠르게 복원할 수 있습니다.보안 비밀, 키, 인증서 3가지 유형 모두 하나의 자격 증명 모음에 저장할 수 있습니다.하지만 환경별로 분리하는 것이 가장 좋습니다.개발용, 테스트용, 운영용 자격 증명 모음을 각각 따로 만드세요.이렇게 하면 실수로 운영 보안 비밀을 개발 환경에서 사용하는 것을 방지하고하나의 자격 증명 모음이 손상되더라도 피해 범위를 제한할 수 있습니다.하지만 보안 비밀을 저장하는 것이 전부는 아닙니다.진짜 중요한 문제는 누가 그 데이터에 접근할 수 있느냐는 것입니다.액세스 제어의 작동 방식에 대해 알아봅시다.이제 누가 접근할 수 있는지 이야기해보겠습니다.키볼트에는 내부 데이터에 대한 액세스를 제어하는 두 가지 방법이 있으며선택에 따라 큰 차이가 발생합니다.첫 번째 모델은 기존 액세스 정책입니다.이는 구식 방식입니다.자격 증명 모음에 직접 정책을 만들고특정 사용자 나 그룹의 보안 비밀, 키, 인증서 같은 특정 데이터 유형에 대한 권한을 할당합니다.문제는 이 정책들이 자격 증명 모음에 직접 연결되어 있다는 점입니다.자격 증명 모음이 여러 개라면 각 모음의 정책을 별도로 관리해야 합니다.확장성이 좋지 않습니다.마이크로소프트는 보안 문제가 알려져 있으므로이제 이 정책의 사용을 권장하지 않습니다.이 방식은 권한 있는 아이디 관리를 지원하지 않으며예상치 못한 권한 상승 경로를 만들 수 있습니다.두 번째 모델은 에이저 RBAC, 즉 역할 기반 액세스 제어입니다.이것이 최신 방식입니다.엔트라 아이디 아이디를 사용하며에이저 위 다른 모든 권한 관리 방식과 일관성을 유지합니다.스토리지 계정이나 가상 머신에 액세스 권한을 부여하는 방법을 이미 알고 있다면키볼트에 권한을 부여하는 방법도 이미 아는 셈입니다.동일한 시스템, 동일한 패턴입니다.

여기서 가장 중요한 원칙은 최소 권한의 원칙입니다.꼭 필요한 최소한의 액세스 권한만 부여하고그 이상은 주지 마세요.보안 비밀을 읽기만 하면 되는 사람에게생성이나 삭제 권한을 주지 마십시오.인증서만 관리하면 되는 사람에게키에 대한 액세스 권한을 주지 마십시오.주요 역할들을 살펴보겠습니다.먼저 키볼트 읽기 권한자 리더 가 있습니다.이는 보안 비밀 목록을 나열할 수는 있지만그 값은 읽을 수 없게 합니다.키볼트 보안 비밀 사용자 시크리츠 유저 가 있습니다.이 권한은 보안 비밀 값을 실제로 읽을 수 있게 해줍니다.그리고 키볼트 보안 비밀 관리자 시크리츠 오피서 가 있습니다.이 권한은 보안 비밀을 생성, 업데이트, 삭제할 수 있게 합니다.패턴이 보이시나요?각 역할은 자격증명 모음 자체가 아니라그 안에 있는 데이터에 특화되어 있습니다.이제 소유자, 기여자, 읽기 권한자와 같은광범위한 역할과 비교해보겠습니다.이 역할들은 리소스인 자격증명 모음, 볼트에 적용되는 것이지그 내부 데이터에 적용되는 것이 아닙니다.소유자는 자격증명 모음 전체를 삭제할 수 있습니다.기여자는 자격증명 모음 설정을 수정할 수 있습니다.하지만 이 역할들만으로는 내부의 비밀 정보에 접근할 수 없습니다.그것은 별도의 권한 계층이며 핵심이 되는 부분입니다.액세스 제어는 계층형 구조로 되어 있습니다.첫 번째 계층인 자격증명 모음 자체에 대한 액세스 권한이 필요하고두 번째 계층인 모음 내부 데이터에 대한 액세스 권한이 필요합니다.둘 다 별도로 부여되어야 합니다.대부분의 초보자는 첫 번째 계층만 생각하고두 번째 계층은 잊어버립니다.거기서 문제가 시작됩니다.가장 흔한 보안 실수죠.중요한 점이 있습니다.대부분의 사람은 키볼트 기여자 역할을 보고 안전하다고 생각합니다.기여자라는 단어를 보고 설정만 관리할 뿐 내부의 비밀은 건드릴 수 없다고 가정합니다.

실제로 마이크로소프트의 자체 문서도 처음에는 정확히 그렇게 명시했습니다.이 역할은 비밀, 키, 인증서에 액세스할 수 없다고 되어 있습니다.하지만 사실은 그렇지 않습니다.키볼트 기여자 역할이 있는 사용자는자격증명 모음의 액세스 정책을 수정할 수 있습니다.여전히 기존 레거시, 액세스 정책을 사용하는 자격증명 모음이라면이 사용자는 모든 비밀, 키, 인증서에 대한 전체 읽기 권한을 스스로 부여할 수 있습니다.특별한 익스플로잇도 패치할 취약점도 필요 없습니다.권한이 원래 그렇게 작동하기 때문입니다.데이터도위 보안 연구원들이 2024년에 이를 입증했습니다.그들은 기여자가 기존 액세스 정책을 사용하는 모든 자격증명 모음에서데이터 전체 액세스 권한으로 승격할 수 있음을 보여주었습니다.마이크로소프트의 대응은 흥미로웠습니다.그들은 이것이 취약점이 아니라고 했는데기여자는 액세스 정책을 관리하도록 설계되었기 때문입니다.하지만 동시에 해당 역할이 데이터 평면 액세스 권한을스스로 부여할 수 있다는 경고 문구를 문서에 명시했습니다.결국, 이건 키볼트 자체의 버그가 아니라 구성상이 함정입니다.역할 이름이 무해하게 들리기 때문에 숙련된 팀들도 속아 넘어갑니다.기여자라는 말은 데이터베이스 비밀번호를 읽을 수 있는 사람처럼 들리지 않지만실제로는 가능합니다.위험성을 생각해보십시오.공격자가 기아의 키볼트에서 기여자 역할이 있는 계정을 탈취한다면모음을 강제로 해킹할 필요가 없습니다.암호를 해독할 필요도 없습니다.그저 액세스 정책을 수정하여 스스로 읽기 권한을 부여하고저장된 모든 비밀, 연결 문자열, API 키, 인증서 등 모든 것을 조용히 유출할 뿐입니다.액세스 정책 변경은 일반적인 관리 활동이므로경고가 울리지 않을 수도 있습니다.그렇다면 해결책은 무엇일까요?첫째, 기존 액세스 정책 대신 데이터 평면 액세스의 에이저 RBAC를 사용하십시오.

RBAC는 자격증명 모음의 관리 권한과 내부 데이터에 대한 권한을 분리합니다.둘째, 반드시 필요한 경우가 아니라면 누구에게도 키자격증명 모음 기여자 역할을 부여하지 마십시오.셋째, 이미 해당 역할을 가진 사용자가 있다면 오늘 바로 감사하십시오.기여자 역할을 키자격증명 모음 비밀 사용자 나키자격증명 모음 비밀 관리자와 같은더 구체적인 역할로 대체하십시오.이 문제를 악화시키는 두 번째 실수가 있는데, 바로 모든 비밀을 하나의 자격증명 모음에 넣는 것입니다.개발, 테스트, 스테이징, 프로덕션 등 모든 환경과 모든 애플리케이션을 위해하나의 자격증명 모음만 사용하다가 해당 모음이 침해되면 모든 것이 노출됩니다.이는 반일 장애 지점이 됩니다.다중 자격증명 모음 전략에 대해서는 잠시 후 자세히 다루겠지만, 원칙은 간단합니다.특히 전체 인프라에 열쇠를 쥐고 있는 바구니라면 모든 달걀을 한 곳에 담지 마십시오.관리 아이디, 이것이 바로 업계 표준입니다.그렇다면 어떻게 올바르게 구현할 수 있을까요?키 자격증명 모음에 액세스하는 가장 좋은 방법에 대해 이야기해보겠습니다.근본적인 문제가 하나 있습니다.키 자격증명 모음에서 자격증명을 가져오려면 애플리케이션이 스스로 인증해야 하는데,인증하려면 자격증명이 필요합니다.앱이 자격증명을 얻기 위해 사용하는 자격증명은 어디에 저장할까요?닭이 먼저 냐 달걀이 먼저 냐의 문제입니다.과거의 해결책은 클라이언트 비밀이 포함된 서비스 주체를 사용하는 것이었지만,그 클라이언트 비밀은 구성 파일, 환경 변수 또는 배포 파이프라인 등 어딘가에 존재해야 합니다.결국 다시 같은 문제로 돌아오게 됩니다.비밀을 단지 다른 곳으로 옮겼을 뿐입니다.관리 아이디는 이 문제를 완전히 해결합니다.작동 방식은 다음과 같습니다.웹앱, 함수, 가상 머신과 같은 에이저 리소스에서 관리 아이디를 활성화하면,에이저가 자동으로 엔트라 아이디에 해당 리소스의 아이디를 생성합니다.

이 아이디는 전적으로 에이저에서 관리합니다.생성할 자격증명도, 순환시킬 비밀도, 저장할 항목도 없습니다.리소스는 에이저가 인지하는 고유한 아이디를 갖게 될 뿐입니다.관리 아이디에는 두 가지 유형이 있습니다.시스템 할당관리 아이디는 특정 리소스 하나에 연결됩니다.해당 리소스를 삭제하면 아이디도 함께 사라집니다.둘은 수명주기를 공유함으로 관리가 간편합니다.사용자 할당관리 아이디는 여러 리소스에 할당할 수 있는 독립적인 아이디입니다.어떤 리소스와도 수명주기를 공유하지 않으므로 여러 서비스에서 동일한 아이디가 필요할 때 유용합니다.실제 적용 모습은 다음과 같습니다.데이터베이스 연결 문자열을 키자격증명 모음에서 읽어야 하는 웹앱이 있다고 가정해봅시다.웹앱에서 시스템 할당관리 아이디를 활성화합니다.그런 다음 자격증명 모음에서 해당 아이디의 키 자격증명 모음 비밀 사용자 역할을 부여합니다.이것으로 끊입니다.코드 내 연결 문자열 또 구성파일 내 클라이언트 비밀도 필요 없습니다.웹앱은 관리 아이디를 사용하여 키볼트에 인증하며 에이저가 내부적으로 모든 자격증명 관리를 처리합니다.이는 에이저에서 자격증명이 필요 없는 인증에 가장 가까운 방식입니다.가장 흔한 공격 경로인 자격증명 탈출을 제거하기 때문에 보안의 판도를 바꿀 수 있습니다.훔칠 자격증명이 없다면 공격자가 손상시킬 대상도 없는 셈입니다.실제 사례를 들어보겠습니다.시냅스 위 데이터 파이프라인이 스토리지 계정에 액세스해야 한다고 가정해봅시다.과거에는 파이프라인 구성에 스토리지 계정키를 저장하곤 했습니다.누군가 그 파이프라인에 액세스 할 수 있다면 그들은 바로 그 키를 갖게 되는 것이 없습니다.관리 아이디를 사용하면 시냅스 작업 영역에 고유한 아이디가 부여됩니다.그 아이디에 스토리지 계정키가 저장된 키볼트에 대한 액세스 권한이 부여됩니다.파이프라인은 런타임에 키를 가져와 사용하며 어디에도 키를 저장하지 않습니다.

코드에 키도 없고 파이프라인 구성에 비밀 정보도 없습니다.관리 아이디와 RBA시 및 최소 권한 원칙을 결합하면 모든 에이저 워크로드를 위한 안전한 기반이 마련됩니다.애플리케이션이 자격 증명 없이 인증을 수행합니다.필요한 것에만 액세스하며 모든 액세스는 기록되고 감사할 수 있습니다.이는 거의 모든 시나리오에 대해 마이크로소프트가 권장하는 패턴입니다.한 번 사용하기 시작하면 왜 이전에는 다른 방식을 썼는지 위하에 할 것입니다.비용 및 다중 볼트 전략이제 비용에 대해 이야기해보겠습니다.이 부분에서 대부분의 사람들이 놀라곤 합니다.에이저 키 볼트는 실제로 비용이 얼마나 들까요?가격 모델은 간단합니다.비밀 항목 당 저장 비용은 없습니다.저장하는 각 암호나 api 키에 대해 비용을 지불하지 않습니다.대신 작업 단위로 요금이 부과됩니다.표준계층의 경우 만 번이 작업당 약 3센트입니다.비밀 항목 가져오기 호출 한 번이 한 번이 작업으로 간주됩니다.비밀 항목을 생성하거나 볼트 내 항목을 나열하는 작업도 마찬가지입니다.일반적인 중소형 애플리케이션의 경우 한 달에 몇 센트 정도면 충분합니다.말 그대로 몇 센트 수준이죠. aws 시크릿 매니저와 비교해보십시오. aws는 비밀 항목 당 월 40센트의 저장 비용을 부과하며 api 호출에 대한 추가 요금도 발생합니다. 100개의 비밀 항목이 있다면 하나도 읽기 전에 이미 한 달에 40달러가 나가는 셈입니다.에이저 키 볼트를 사용하면 100개의 비밀 항목을 적당히 사용할 때 약 15센트 정도가 듭니다.규모가 커질 수록이 차이는 빠르게 벌어집니다.물론 프리미엄 계층도 있습니다.이 계층은 최고 수준의 암호화 보증이 필요한 워크로드를 위해 hsm 기반 키를 제공합니다.금융 거래, 의료 데이터, 정보 시스템 등을 예로 들 수 있습니다.작업당 비용은 더 높아서 고급 키 유형의 경우 만 번이 작업당 약 15센트이며 hsm 키당 월별 요금이 추가됩니다.

하지만 대부분의 애플리케이션에는 표준 계층만으로도 차고 넘칩니다.사람들이 예상치 못하게 놀라는 비용 관련 사실이 하나 있습니다.일반적인 웹앱에서 소수의 보안 비밀과 매달 수천 건의 작업을 수행할 때 키 볼트 비용은 1달러 미만입니다.설정하면서 마시는 커피 값이 더 나올 겁니다.하지만 비용보다 더 중요한 전략이 있습니다.얼마나 많은 자격 증명 모음을 사용하는가 하는 점입니다.현명한 접근 방식은 다중 자격 증명 모음 전략을 사용하는 것입니다.개발, 테스트, 스테이징, 프로덕션 환경에 각각 별도의 자격 증명 모음을 사용하세요.이렇게 하면 가장 흔한 사고를 방지할 수 있습니다.테스트 스크립트를 실행하다가 같은 자격 증명 모음에 있던 연결 문자열 때문에 실수로 프로덕션 데이터베이스를 읽는 경우죠.환경을 분리하면 그런 실수는 불가능해집니다.비즈니스 단위나 규정 준수 영역별로도 분리해야 합니다.결제 카드 데이터를 다룬다면 해당 보안 비밀은 별도의 자격 증명 모음에 보관하세요.일반 비즈니스 워크로드는 다른 곳에, 의료 데이터는 또 다른 곳에 보관하는 식입니다.이는 까다롭게 굴려는 것이 아니라 피해 범위를 제한하기 위한 것입니다.하나의 자격 증명 모음이 손상되더라도 해당 모음의 보안 비밀만 노출됩니다.나머지 인프라는 안전하게 유지됩니다.그리고 항상 활성화해야 할 두 가지 기본 안전장치가 있습니다.소프트 삭제는 누군가 보안 비밀을 삭제해도 연구적으로 사라지지 않는다는 의미입니다.보안 비밀은 최대 90일까지 선택한 보존 기간 동안 복구 가능한 상태가 됩니다.제거 보호는 여기서 한 걸음 더 나아갑니다.보존 기간이 만료되기 전까지는 누구도 자격 증명 모음이나 그 내용을 연구적으로 삭제할 수 없습니다.이 두 가지 기능을 함께 사용하면 보안팀을 방짬 설치게 하는 예기치 않은 데이터 손실을 방지할 수 있습니다.모든 것이 연결되는 방식입니다.

이 모든 것을 종합하여 각 요소가 어떻게 맞물리는지 살펴보겠습니다.키볼트는 고립된 섬이 아닙니다.에이저 아키텍처 내 보안 비밀을 위한 중추 신경계와 같습니다.전체 시스템의 흐름을 이해하면 모든 것이 자연스럽게 연결됩니다.애플리케이션이 보안 비밀을 필요로 할 때 어떤 일이 일어나는지 보겠습니다.애플리케이션은 관리 아이디를 사용하여 요청합니다.해당 아이디는 이미 엔트라 아이디에 등록되어 있습니다.리소스에서 관리 아이디를 활성화하면 에이저가 자동으로 생성합니다.엔트라 아이디는 해당 아이디가 유효한지 검증한 후 키볼트로 요청을 전달합니다.키볼트는 할당한 RBAC 권한을 확인합니다.아이디에 키볼트 보안 비밀 사용자와 같은 올바른 역할이 있다면 보안 비밀이 반환됩니다.이 모든 과정은 밀리초 단위로 이루어집니다.애플리케이션은 자격 증명을 직접 확인하지 않습니다.비밀번호를 저장하지도 않습니다.필요한 값만 가져올 뿐입니다.이제 얼마나 많은 에이저 서비스가 여기에 연결될 수 있는지 생각해보세요.앱 서비스, 펑션스, AKS, 데이터 팩토리, 시냅스, 로직 앱스, DevOps 파이프라인즈 모두 키볼트와 통신하는 방법을 알고 있습니다.웹 앱을 구성하여 애플리케이션 설정에서 보안 비밀을 직접 참조하게 할 수 있습니다.데이터 팩토리 파이프라인이 런타임의 키볼트에서 스토리지 계정 키를 가져오도록 설정할 수도 있습니다.키볼트 CSI 드라이버를 사용하여 키번의 클러스터가 비밀을 가져오도록 구성할 수 있습니다.모든 서비스는 동일한 ID 시스템, 동일한 RBAC 역할, 동일한 감사로깅을 사용하여 동일한 방식으로 통합됩니다. CI, CD 패턴은 특히 강력합니다.파이프라인은 배포 시점에 키볼트에서 비밀을 가져옵니다.파이프라인 변수 나 리포지토리 비밀에 저장하지 않습니다.데이터베이스 비밀번호를 교체해야 하는 경우 키볼트에서 업데이트하면 됩니다.

다음에 파이프라인이 실행될 때 자동으로 새로운 값을 가져옵니다.파이프라인 변경도, 코드 수정도, 재배포도 필요 없습니다.이 모든 것을 가능하게 하는 핵심은 바로 이것입니다.관리 ID와 RBAC으로 키볼트를 설정하면 자격증명 관리에 대해 더 이상 고민할 필요가 없습니다.애플리케이션은 그대로 작동합니다.비밀은 아무도 모르게 교체됩니다.인증서는 한방중에 비상사태 없이 갱신됩니다.시스템이 백그라운드에서의 모든 것을 처리합니다.이것이 바로 중요한 보안태세입니다.네트워크가 아닌 ID가 경계가 됩니다.누군가 가상 네트워크 내부에 있든 외부에 있든 상관없습니다.중요한 것은 적절한 권한을 가진 유효한 ID를 보유했는지 여부입니다.키볼트는 설계상 이를 강제합니다.모든 액세스 요청은 요청 출처와 관계없이 엔트라 ID 인증 및 RBAC 권한 부여를 거칩니다.그리고 모든 것이 기록됩니다.모든 비밀 읽기, 모든 키 작업, 모든 인증서 검색이 기록됩니다.누가 언제 무엇에 액세스했는지 확인할 수 있습니다.의심스러운 점이 있으면 조사할 데이터가 확보되어 있습니다.이는 규정 준수, 사고 대응, 그리고 환경 내 상황 파악을 위해 매우 중요합니다.그것이 바로 이 시스템의 장점입니다.키볼트, 엔트라 ID, RBAC 및 관리 ID는 통합보안 프레임 워크로서 함께 작동합니다.각 구성 요소는 서로를 강화합니다.모두 올바르게 설정되면 직접 구축하는 것보다 훨씬 더 안전하고 운영하기 간단한 자격증명 관리 시스템을 갖게 됩니다.실천 가능한 핵심 내용입니다.그렇다면 지금 당장 무엇을 해야 할까요?이 지식을 행동으로 옮겨봅시다.이번 주에 바로 실행할 수 있는 사항들입니다.권한 모델부터 시작하세요.포털에서 키볼트를 열고 액세스 구성을 확인해보세요.자격증명 모음 액세스 정책이 보인다면 그것은 구식 방식입니다.대신 에이저 역할 기반 액세스 제어를 사용해야 합니다.

마이그레이션은 간단합니다.권한 모델을 전환하고 기존의 액세스 정책을 가졌던 사람들에게 rbac 역할을 할당하세요.오늘 바로 실행하세요.마이크로소프트가 권장하는 방식이며 우리가 논의한 연구 결과가 그 이유를 정확히 보여줍니다.다음으로 키볼트 기여자 역할을 가진 계정을 감사하세요.볼트 위 iam 블레이드를 열어 누가 기여자 액세스 권한을 가지고 있는지 살펴보세요.해당 역할을 가진 모든 사람은 파당한 이유를 가지고 있어야 합니다.대부분의 경우 그렇지 않습니다.기여자 컨트리뷰터 역할을 더 구체적인 것으로 바꾸세요.비밀값을 읽기만 하면 된다면 키볼트 비밀 사용자 역할을 부여하세요.

권한 상승 경로를 완전히 차단하는 것입니다.다음으로 관리 아이디를 활용하세요.키볼트에 액세스해야 하는 모든 에이저 서비스는 이를 사용해야 합니다.웹앱, 함수, 데이터 팩토리 또는 가상 머신이 여전히 클라이언트 암호가 포함된 서비스 주체를 사용 중이 라면 관리 아이디로 전환하세요.더 간단하고 안전하며 앞서 다룬 닭과 달걀 문제를 해결해줍니다.에이저가 백그라운드에서 자격증명 관리를 대신 처리해줍니다.한 가지 더 모든 자격증명 모음에서 일시 삭제 및 제거보호를 활성화하세요.새 자격증명 모음은 일시 삭제가 기본적으로 켜져있지만 제거보호는 그렇지 않습니다.이를 켜세요.이 설정은 보존기간 동안 누구도 자격증명 모음이나 그 내용을 연구적으로 삭제하지 못하게 합니다.이미 여러 팀리의 기능 덕분에 치명적인 실수를 피했습니다.이제 실천할 시간입니다.현재의 비밀관리 방식을 점검해보세요.구성 파일, 환경 변수 또는 코드에 하드코딩되어 남아있는 비밀값을 하나 찾으세요.이번 주에 키볼트로 옮기세요.딱 하나만요.얼마나 간단한지 확인하고 나면 나머지도 옮기고 싶어질 겁니다.보안은 한 번 설정으로 끝나는 게 아닙니다.

도구는 이미 준비되어 있습니다.패턴은 이미 검증되었습니다.이제 이를 구현하는 것은 여러분의 목입니다.그것이 시스템입니다.키볼트는 여러분의 디지털 금고이지만 그 주변에 설정한 액세스 제어만큼만 안전합니다.제가 설명한 감사부터 시작하세요.권한 모델을 확인하세요.기여자 할당을 검토하고 이번 주에 비밀값 하나를 자격증명 모음으로 옮기세요.더 많은 클라우드 보안 정보를 쉽게 확인하려면 구독하시고여전히 구성 파일에 비밀값을 저장하는 분들에게 이 영상을 공유해주세요.