Microsoft Entra ID

서비스가 두세 개로 늘어나면 각 서비스가 로그인을 따로 관리하는 구조가 문제를 만듭니다. 사용자는 서비스마다 다른 비밀번호를 관리해야 하고, 팀은 인증 로직을 반복해서 구현해야 합니다. 퇴사자가 생겼을 때 모든 서비스의 계정을 일일이 찾아서 차단해야 하고, 외부 SaaS까지 섞이면 어디서 누가 접근할 수 있는지 파악조차 어려워집니다. 비밀번호 유출 한 건이 여러 시스템에 동시에 파급되고, 통합 감사 로그도 없어서 사후 추적도 막막해집니다.

초기에는 각 애플리케이션이 자체 사용자 테이블을 두고 인증을 처리했습니다. 서비스 수가 적을 때는 이것으로 충분했지만, 기업 환경에서 사내 시스템이 수십 개로 늘고 클라우드 SaaS까지 더해지면서 계정 분산과 퇴사자 접근 통제 누락이 반복적인 운영 사고로 이어졌습니다. 온프레미스 환경에서는 사내망 안에서 도메인 기반으로 이 문제를 처리할 수 있었지만, 사용자가 외부 네트워크에서도 접속하고 앱이 여러 클라우드에 흩어지면서 네트워크 경계를 신뢰의 기준으로 삼기 어려워졌습니다. 그 결과 '이 네트워크 안에 있는가'가 아니라 '이 사용자가 누구인가'를 중심으로 접근을 제어하는 ID 기반 플랫폼이 필요해졌습니다.

Entra ID는 사용자가 로그인하면 자격 증명을 검증한 뒤 토큰을 발급합니다. 애플리케이션은 이 토큰만 받아서 사용자 신원과 권한을 판단하고, 직접 비밀번호를 다루지 않습니다. 토큰은 OAuth 2.0과 OpenID Connect 표준을 따르므로, 자체 개발 앱뿐 아니라 표준을 지원하는 외부 SaaS에도 같은 계정으로 접근할 수 있습니다. 로그인 시점에 조건부 접근 정책이 적용됩니다. 접속 위치, 디바이스 등록 여부, 로그인 위험 수준에 따라 추가 인증을 요구하거나 접근 자체를 차단할 수 있습니다. MFA는 비밀번호가 유출되더라도 앱 알림이나 생체 인식 같은 두 번째 인증 수단이 있어야 통과되도록 합니다. Azure 리소스에 접근해야 하는 서비스에는 Managed Identity를 부여할 수 있습니다. 코드에 자격 증명을 넣지 않아도 플랫폼이 자동으로 토큰을 처리해 주는 방식이라, 자격 증명 관리 부담과 유출 위험을 동시에 줄입니다.

온프레미스 Active Directory(AD)와 Entra ID는 둘 다 조직 안에서 누가 무엇에 접근할 수 있는지를 관리합니다. AD는 사내 네트워크 안에서 Kerberos와 LDAP으로 동작하는 디렉터리 서비스로, 도메인에 가입된 윈도우 PC와 서버를 관리하는 데 강점이 있습니다. Entra ID는 클라우드와 SaaS를 전제로 OAuth/OIDC 기반으로 동작하며, 웹 앱과 모바일 앱, 외부 서비스에 대한 SSO와 조건부 접근에 적합합니다. 많은 조직이 AD Connect로 두 시스템을 동기화해서 함께 쓰지만, 클라우드 네이티브 환경에서 새로 시작하는 경우에는 Entra ID만으로 충분한 경우가 많습니다. 관리 대상이 사내 도메인 장비 중심이면 AD가, 클라우드 앱과 API 중심이면 Entra ID가 자연스럽게 맞습니다. 다만 Entra ID는 네트워크 수준의 격리나 방화벽 규칙은 다루지 않으므로, 인프라 보안은 별도로 설계해야 합니다.

새 웹 앱을 만들 때 인증을 직접 구현하지 않고 Entra ID에 앱을 등록해 OAuth 플로우를 연결하면, SSO와 MFA를 별도 구현 없이 쓸 수 있습니다. 퇴사자가 생겼을 때 Entra ID 계정을 비활성화하면 연결된 모든 서비스 접근이 한 번에 끊기는 구조도 여기서 나옵니다. 마이크로서비스 팀에서는 서비스 간 통신에 Managed Identity를 써서 자격 증명을 코드에서 제거하는 방식을 많이 씁니다. 어느 서비스가 어느 리소스에 접근했는지 Entra ID 로그에서 추적할 수 있어서, 보안 감사 요구가 있는 환경에서도 유용합니다. 다만 Entra ID는 '누가, 무엇에 접근할 수 있는가'를 다루는 것이지, 비밀 값 보관이나 데이터 암호화는 별도 서비스가 담당합니다. 또한 MFA나 조건부 접근 정책은 라이선스 등급에 따라 사용 가능 여부가 달라지므로, 도입 전에 플랜을 확인해야 합니다.