Cisco AnyConnect는 리모트 VPN으로 유명하다. VPN을 접속하기 위해서는 인증 과정이 필요한데, 이때 사용되는 방법은 RADIUS, TACACS, LDAP 등이 있다. 이러한 인증 방법은 10년전까지만해도 대세였지만, 이제는 클라우드를 통한 인증이 대세가 되었다. 이 포스팅은 왜 클라우드로 인증을 하는 것이 대세이며, 그 과정에서 생각해보아야 할 과제에 대해서 조명해보려고 한다. 포스팅의 마지막 부분은 AnyConnect와 Azure AD를 이용한 SAML 인증하는 방법을 Step-by-Step으로 설명한다.
내가 Junior Engineer로 일할 때 나에게 조언을 준 Senior Engineer가 있었다. 그때 한 말이 아직까지 기억에 남는다. 당신이 단순히 매뉴얼만 따라해서 프로젝트를 끝낸다면, 그것은 Engineer의 일이 아니다. 아마 누구라도 시간이 주어지는 한 할 수 있을 일일 것이다. Engineer는 매뉴얼에 나온 기술에 자신의 한계를 설정하지 않고, 기술의 코어 컨셉을 정확하게 이해함으로서 매뉴얼에서 주어지는 기술을 넘어서 이것을 다른 분야에 적용하는 사람이다.
이를 동일하게 이 포스팅에 적용해서, Cisco AnyConnect와 Azure AD와의 SAML Integration에 필요한 컨셉을 정리해보자.
AnyConnect와 Azure AD Integration을 위해서는 SAML 이라는 시큐리티 도메인을 이해해야 한다.
Cisco AnyConnect의 기능은 계속 추가가 되어지고 있다. AnyConnect는 이제는 단순 VPN 기능 뿐만 아니라, Cisco Umbrella와 같은 DNS security 도 추가되어 있다. 하지만 이번 포스팅에서는 AnyConnect의 VPN 기능에 포커스를 한다. AnyConnect는 사용자들이 VPN을 통해서 리모트 사이트에 연결될 수 있도록 돕는 어플리케이션이다. AnyConnect가 직접적으로 커뮤니케이션 하는 서버가 바로 Cisco ASA (Adapative Security Appliance) 혹은 FTD (FirePower Threat Defense) 이다. 쉽게 말하면 VPN 서버가 바로 Cisco ASA 혹은 FTD가 되는 것이며, 위의 삼각형에서는 가장 윗쪽 부분에 해당한다. SAML 연동 과장에서는 Cisco ASA가 Service Provider (SP)가 된다. User가 VPN에 연결하기 위해서 사용되는 앱이 바로 AnyConnect이고, 이를 돕는 서버가 바로 ASA이다. 그리고 이때 인증의 핵심 (IdP)가 바로 Azure AD가 되는 것이다.
SAML은 무엇인가?
SAML (Security Assertion Markup Language) 은 시큐리티 도메인 안에서 authentication과 authorization을 컨트롤하는 XML-based framework이다. SAML은 Security Domain 안에서 User, Service Provider (SP), 그리고 Identity Provider (IdP)간의 Circle of Trust 을 만든다. 위의 삼각형을 원으로 생각하면 된다. 이 신뢰 관계를 통해서 User, SP, 그리고 IdP가 서로 정보를 교환하는 방식을 SAML이라고 생각하면 된다.
SAML에 필요한 Metadata: SP와 IdP가 안전하게 커뮤니케이션 할 수 있도록 만들어진 XML based 문서이다.
Cisco ASA를 포함해서 하드웨어 Device 자체가 IdP와 SP의 역할을 동시에 할 수 있다. 즉, Cisco ASA가 중간 매개체인 SP가 될 수도 있고, 고객의 ID와 패스워드를 지닌 IdP가 될 수도 있다. 대부분의 경우 복수의 IdP도 모든 하드웨어가 지원하고 있다. 예를들면, Azure AD 이외에도 Duo, Okta와 같은 IdP도 동시에 지원하고 있다. 하지만, 이 때 IdP Identifier가 동일할 경우 약간의 변동 사항이 생긴다. 특별히 Azure AD의 경우 Azure AD Identifier가 Tenant 당 하나씩 주어진다. 만약 Cisco ASA에서 여러개의 Tunnel Group을 (복수의 AnyConnect Profile을 가진 경우) 있는 경우에는 Configuration을 조금 바꿔줘야 한다. 이런 경우에는 Azure portal 에서 동일한 CA certificate을 사용하면 Cisco AnyConnect에서 복수의 Tunnel Group 문제를 해결할 수 있다. 아쉽게도 이 부분에 대한 설명은 Microsoft Doc과 Cisco 웹사이트에서도 쉽지 찾을 수 없었다.
SSO란 무엇인가? (Single Sign-On)
IdP (Azure AD)는 User가 한번 로그인을 한 후에 다른 여러가지 서비스도 동시에 로그인할 수 있게 한다. 이것이 바로 SSO을 사용하는 가장 큰 이유이다. Gmail 혹은 Facebook의 로그인 상태로 다른 앱에 아무런 제약없이 (ID와 패스워드 없이) 이용할 수 있는 것이 바로 SSO의 좋은 예이다. 앱 개발자들의 입장에서는 사용자의 ID 와 Password등의 관리를 따로 하지 않게 되어 편리하고, 사용자들도 매번 ID와 Password을 만드는 번거로움을 피하게 되었다. 만일 앱 유저들이 만명이 넘는다면, 만명에 대한 User ID와 Password을 관리하는 데도 많은 인력과 돈, 그리고 시간이 소모될 것이다. 이러한 번거로움을 SSO가 해결해 준 것이다.
이 포스팅에서 SP는 Cisco ASA이며, IdP는 Microsoft Azure AD이다. Microsoft Azure AD를 사용하는 가장 큰 이유는 아마도 MFA (Multi Factor Authentication)일 것이다. 즉, 패스워드 이외에 Token 혹은 Microsoft Authenticator App을 사용하여서 2중 인증을 만들어 더 보안을 강화하기 위해서이다.
왜 Azure AD을 사용해서 SSO을 구지 해야할까?
Azure AD을 이용해서 SSO을 사용하는 첫번째 이유는 사용자 편의를 위해서이다. 매번 ID와 Password을 입력하지 않고 한번의 로그인을 통해서 VPN 뿐만 아니라, 다른 서비스들도 사용이 가능하기 때문이다. 보통의 경우 Microsoft Outlook, Microsoft Team, Office 365등의 서비스들은 이미 Azure AD을 통해서 인증을 하여야만 사용이 된다. 즉 Microsoft 계정으로 한번만 인증이 되면 SAML과 연계된 다른 서비스들은 패스워드 없이도 사용이 가능한 것이다. 규모가 어느 정도 큰 회사인 경우 Microsoft Exchange 혹은 Azure Active Directory를 이미 가지고 있기에 특별히 SAML을 구현하는데 어려움은 없을 것이다.
Azure AD을 이용해서 SSO을 사용하는 두번째 이유는 보안을 위해서이다. 앞서 언급했던 RADIUS, TACACS, LDAP 등은 대부분 Backend에 있는 Directory Service을 이용해서 사용자와 패스워드를 확인 한후 인증 과정이 이루어진다. 이러한 인증 방법 역시 Audit log을 가지고 있다. 즉, 유저가 언제 접속했는지를 알 수 있다. 하지만, Azure AD의 경우 유저의 접속 시간, IP address, 접속한 지역 혹은 나라, 접속하는 방법이 이전과 달리 특이한 점이 있는지를 모두 확인한 후에 이를 블락하거나 Security Center 로 정보를 넘길 수 있는 기능이 있다. 즉, Azure Cloud에 있는 Security 기능을 모두 사용할 수 있기 때문에 더 안전한 보안 상태를 유지할 수 있게 되는 것이다.
이 보안 중에 하나가 바로 MFA (Multi Factor Authentication)이다. 이외에도 Azure Conditional Access Policy을 이용할 경우, 특정한 나라에서 VPN 접속을 차단할 수도 있으며, 접속하는 기종과 시간대별로도 접속을 차단할 수 있다. 예를들어 허가되지 않은 컴퓨터에서 VPN을 접속하지 못하도록 할수 있다. 이러한 기능들은 기존 RADIUS, TACACS, LDAP 등에서 할 수 없는 보안 기능이다.
실전 Step-by-Step Cisco AnyConnect와 Azure AD SAML Integration 해보기
이제부터 실제로 어떻게 SP와 IdP를 SAML을 통해서 연결하는지 살펴보자.
우선 Cisco AnyConnect와 ASA 버전은 적어도 아래의 버전을 가지고 있어야 한다.
- Cisco ASA 9.7+ (FTD 도 가능하다)
- AnyConnect 4.6+
Azure AD Configuration
1. Azure Portal에서 Azure Activie Directory를 선택한다. SSO을 설정하기 위해서 "Enterprise Applications'을 선택한다.
2. All applications - New Application을 선택한 후, Cisco AnyConnect app을 Azure Portal Gallery에서 선택해서 인스톨한다.
3. Cisco 라고 검색창에 넣으면 Cisco 관련 모든 App을 Azure portal gallery에서 찾을 수 있다. 우리가 선택할 것은 Cisco AnyConnect
4. Cisco AnyConnect을 선택한 후에는 "Name"을 설정하라고 보인다. 여기에 Default로 Cisco AnyConnect라고 써있는데, 이것을 AnyConnect Profile로 바꿔주는 것을 추천한다. 예를들어, ABC.com에 Profile이 2개가 있다고 가정해보자. Profile A는 보통 유저들을 위한 것이고, Profile B는 컨트랙터를 위한 프로파일인 경우라면 "AnyConnect Profile User" 혹은
"AnyConnect Profie Contractor"라고 이름을 지어주는 것이다. 이렇게 이름을 나눠주는 이유는 복수의 Profile의 경우 이름을 달리하여 구분하기 위해서이다. 이 실습에서는 2개의 다른 AnyConnect Profiles (Profile User & Profile Contractor)를 각각 설정할 것이다. 그렇기 때문에 여기에서는 Cisco AnyConnect Profile User라고 이름을 명명하고 "Create"을 누른다.
5. 새로 만든 "Cisco AnyConnect Profile User"가 생성된 후에는 VPN에 접속할 "Users and Groups" 을 선택한다. Azure AD가 준비가 된 경우에는, ADSync를 사용해서 AD의 Group들이 Azure 로 씽크가 되어 있을 것이다. VPN을 이전부터 사용했던 경우에는 대부분 Security Group을 이미 가지고 있는 상태일 것이고, 이 경우 기존에 사용했던 AD의 VPN 그룹을 설정하면 된다. VPN 사용을 하지 않았던 경우에는 새로 Group을 만들거나, 유저를 수동으로 추가할 수도 있다.
6. 테스트를 위해서 AD에 있는 mfatest 어카운트를 유저로 추가해보았다. 이제 유저가 추가되었으니, Signle Sign-on 설정을 해보자. 왼쪽 패널에 "Single Sing-on"을 선택한다.
7. 우리가 선택할 Single Sign-on의 옵션은 바로 SAML 이며, 이것을 선택해준다. SAML에 관한 간단한 설명도 함께 보인다 "Rich and secure authentication to applications using the SAML protocol"
8. Single Sign-on 을 선택한 후에는 Basic SAML Configuration과 SAML Signing Certificate을 설정한다. 첫번째 Basic SAML Configuration "Edit" 을 누르고, Identifier (Entity ID)와 Reply URL (Assertion Consumer Service URL)을 설정한다.
9. Identifier (Entity ID)와 Reply (Assertion Consumer Service URL)은 아래의 포맷과 같다. vpn.ABC.com이 ASA의 서버의 주소이고, 이때 TGTGroup 은 Tunnel Group의 이름이다. 이 경우에는 AnyConnect Profile User가 여기에 해당할 것이다. VPN server가 2개 이상인 경우에는 vpn2.ABC.com으로 설정해주면 된다. 즉, AnyConnect App을 Azure Gallery에서 2번 인스톨해줘야 한다. VPN server가 1개인 경우이지만, AnyConnect의 Profile이 2개 이상일 경우에도 마찬가지로 Azure Gallery에서 Profile 숫자만큼 인스톨해줘야 한다. 이번 예제에서는 1개의 VPN 서버 (ASA)와 2개의 AnyConnect Profile (2개의 Tunnel Group)을 기준으로 설명하기에 AnyConnect App을 2번 Azure Gallery에서 인스톨 해줘야 한다.
Identifier (Entity ID) 패턴
https://vpn.ABC.com/saml/sp/metadata/TGTGroup
Reply URL (Assertion Consumer Service URL) 패턴
https://vpn.ABC.com/+CSCOE+/SAML/SP/ACS
보통의 경우 TGTGroup과 ACS는 같을 것이다 (Tunnel Group = AnyConnect Profile)
10. SAML sign certificate을 설정한다. 여러 개의 Tunnel Group의 경우 Azure Portal에서 SAML Sign Certificate을 동일한 Certificate으로 바꿔주어야만 한다. 이때 Multi domain SAN certificate 혹은 Wildcard certificate을 사용하는 것을 추천한다. "Edit"을 누르면 Azure 자체적으로 지원하는 Certificate이 이미 Active로 되어 있다. 이것을 비활성화 시키고, ASA가 가지고 있는 Certificate을 인스톨한다. (만약 AnyConnect Profile이 1개인 경우에는 이 과정을 스킵해도 되고, 단지 Certificate을 다운로드 받기만 하면 된다. 이 Certificate은 Step 14에서 사용된다). 추가로 설치한 Certificate을 Active로 전환하고, 기존 Azure에서 제공하는 Certificate은 자동으로 Inactive로 전환된다.
AnyConnect Profile이 한개가 아닌 여러개인 경우, 해당 Profile마다 AnyConnect App을 설치해주어야 한다. 즉, AnyConnect Profile이 3개인 경우 보통 3개의 Tunnel Groups이 있을 것이다. 그렇기 때문에 AnyConnect App도 3개를 Azure portal에서 3번 Profile 마다 (Tunnel Group) 설치해주어야 한다.
11. SAML Signing Option은 Sign SAML Assertion을 선택한다. Sign Assertion과 Sign Response의 차이점은 다음과 같다. Azure AD (IdP)가 유저에 대한 인증을 끝마친 후, Cisco ASA (SP)로 인증 확인을 보낸다. Azure AD는 digital signature로 SP와 통신을 하는데 이때 사용되는 것이 우리가 설정한 Certificate이다. Azure AD는 SAML Signing Certificate의 Private key과 Public key을 통해서 SP와의 커뮤니케이션을 검증한다. 이때 SAML Sign Response는 모든 인증 과정을 확인하는 반면에 (보안 강화), SAML Sign Assertion (SSO의 경우 Sign Assertion으로 설정하는 것이 보통)의 경우에는 SP로 간단 인증만 한다고 생각하면 된다. 이와 함께 Notification Email을 설정해 놓으면, Certification Expiration Notice 을 이메일로 받을 수 있다.
12. Signing Certificate 설정 후에는 "Setup Cisco AnyConnect" 칸에 있는 아래의 3가지 정보를 모두 복사해서 보관한다. 이 정보는 후에 ASA 설정을 할 때 사용된다. (Login URL, Azure AD Identifier, Logout URL)
13. (Optional configuration: 추가 설정) 이번 과정은 SSO 과정에 필요하지는 않지만 숙지하고 있으면 보안에 유익한 옵션 셋업이다. Security 섹션 중 Conditional Access을 누른다.
Conditional Access 에는 이미 Built-in 되어 있는 Policy들이 있다. 그 중에 "Allow Cloud App Access - Hybrid Azure AD joined Devices"만 간단히 살펴보자. 이 Policy를 클릭하면 어떤 사항을 컨트롤 할 것인지 자세히 볼 수 있다.
이 Policy는 모든 Cloud Apps 에 해당되며, 2개의 컨디션을 가지고 있고 1개의 Grant (허락, 혹은 거절)의 수행 명령이 있다.
Policy 안에는 2개의 Condition이 있고 그 중 Device platforms을 선택하면 Windows만 포함되어 있는 것을 확인할 수 있다. 즉, 이 Policy에 해당되는 플랫폼은 윈도우 머신만 해당이 된다는 의미이다. 이러한 식으로 플랫폼, 사용자, 위치 등에 따라서 AnyConnect을 사용하는 것을 블락할 수 있다. 예를 들면, 회사에서 제공하는 컴퓨터가 아닌 다른 컴퓨터를 이용할 경우, Conditional Access을 통해서 VPN을 차단할 수도 있다. 이러한 기능이 바로 Azure AD을 사용하는 이유중에 하나이며, 이러한 보안 기능은 기존의 인증 방식에서는 한계가 있다.
이로써 Azure AD 쪽 SAML 설정은 마쳤다. 이제 Service Provider인 Cisco ASA 설정을 살펴보자.
Cisco ASA Configuration
14. 대부분의 Azure와 Cisco 문서에는 아래와 같이 새로운 Trustpoint을 만들라고 하고 있다. 아래의 Config 중 AzureAD-AC-SAML이 바로 Trustpoint 이름이다. 그리고 PEM Certificate 이라고 되어 있는 부분에 Step 10에서 다운로드 받은 Azure certificate을 첨부한다. 2개의 Profile 모두를 Azure AD와 SAML로 연동하기 위해서는 Step 10에서 사용한 SAN certificate을 사용하기 때문에 아래의 Config가 필요하지 않다. 즉, 기존에 ASA에서 사용하고 있는 Trustpoint와 ASA의 Certificate을 재사용하는 것이다.
(AnyConnect 프로파일이 1개인 경우에는 아래의 컨피그로 새로운 Trustpoint와 Azure portal에서 다운로드 받은 Certificate을 복사해서 넣어준다)
crypto ca trustpoint AzureAD-AC-SAML
revocation-check none
no id-usage
enrollment terminal
no ca-check
crypto ca authenticate AzureAD-AC-SAML
-----BEGIN CERTIFICATE-----
…
PEM Certificate Text from download goes here
…
-----END CERTIFICATE-----
quit
15. AnyConnect 프로파일이 2개 이상인 경우에는 Step 14을 스킵했을 것이다. Step 12에서 수집한 정보가 드디어 ASA에 쓰일 차례이다. 위에서부터 순서대로 SAML IdP (Azure AD Identifier), URL Sign-in, 그리고 URL Sign-out 주소를 적어준다. 여기서 가장 중요한 포인트가 바로 trustpoint idp 이다. 복수의 AnyConnect Profile을 가진 경우 trustpoint IdP와 trustpoint SP을 동일한 certificate으로 설정해주어야 한다. 만일 AnyConnect 프로파일이 한개일 경우에는 Step 14에서 만들어준 trustpoint을 "trustpoint idp"에 넣어주면 된다 (AzureAD-AC-SAML).
webvpn
saml idp https://sts.windows.net/xxxxxxxxxxxxx/ (Azure AD Identifier)
url sign-in https://login.microsoftonline.com/xxxx/saml2 (SSO In Service URL)
url sign-out https://login.microsoftonline.com/xxxx/saml2 (SSO Out Service URL)
trustpoint idp (Cisco ASA certificate)
trustpoint sp (Cisco ASA certificate)
no signature
force re-authentication
base-url https://vpn.abc.com
이와 함께 중요한 것은 "force re-authentication" 이다. 이 명령어는 특별히 AnyConnect Profile이 다수인 경우에 유용하게 사용된다. 대부분의 Cisco와 Azure 문서에는 "no force re-authentication" 으로 되어 있다. no re-authentication을 했을 때의 장점은 사용자들이 따로 VPN 연결을 위해서 Microsoft 웹사이트에 인증을 하지 않고, 기존의 Cache로 자동 접속이 가능하다. 예를들어, Microsoft Teams 혹은 Outlook을 사용한다고 가정해보자. 이 경우, 어플리케이션에 접속하기 위해서 Azure Portal에서 로그인을 해야한다. 이렇게 로그인 상태가 Cache로 Browser에 저장되어 있기 때문에 AnyConnect는 자동으로 연결을 시도한다. 하지만, 프로파일이 2개 이상일 경우, 기존에 Cache로 저장된 정보로 AnyConnect을 자동 연결시키기 때문에, 여러개의 프로파일을 고를 수 있는 옵션이 보이지 않는다. 그렇기 때문에, "force re-authentication" 명령어를 사용하여서 원하는 프로파일을 선택할 수 있게 되는 것이다.
16. 이제 SAML identity provider 와 Tunnel Group을 맵핑해준다. 만약 IdP의 Config을 수정해야 한다면, 아래의 컨피그를 다시 실행시켜주어야 한다. 이 명령어를 다시 실행하지 않으면 IdP Config 수정은 효력이 없다.
tunnel-group AnyConnect Profile User webvpn-attributes
saml identity-provider https://sts.windows.net/xxxxxxxxxxxxx/
authentication saml
SAML Identity Provider 정보는 Step 12에서 얻을 수 있다. 위에서도 언급했지만, 하나의 device에는 여러개의 SAML Server (IdP)을 설정할 수 있다. 하지만, 동일한 SAML 서버를 여러번 설정하는 것은 불가능하다. 특별히 ASA에서 동일한 SAML Server를 설정해주면 Error가 난다.
Cisco ASDM으로 ASA을 접속하면 아래와 같은 컨피그 설정이 되어 있는 것을 확인할 수 있다. (Step 14-16)
SSO server의 설정을 확인하기 위해서 Edit을 눌러보자. 그러면 IdP Entity ID, Sign In URL, Sign Out URL을 확인할 수 있다. 그리고 가장 중요한 것이 바로 Identity Provider Certificate과 Service Provider Certificate이 동일하게 설정되어 있나 확인하는 것이다 (복수의 프로파일인 경우). 1개의 프로파일인 경우에는 Azure 에서 다운로드 받은 Certificate을 아래 그림처럼 설정해주면 된다.
17. 마지막으로 Client Address Pools을 설정해주어야 한다. 이 Address Pools은 VPN으로 사용자가 접속했을 때 할당받는 IP이다. DHCP 서버를 통해서 IP를 할당받을 경우는 아래의 Address Pools은 설정하지 않아도 된다. 이 부분은 Cisco와 Microsoft 매뉴얼에 누락된 부분이기도 하다.
AnyConnect 연결 테스트
AnyConnect로 연결을 시도해보자. 연결을 시도한 후에 원하는 AnyConnect profile을 선택하면, 아래와 같이 Cisco AnyConnect Login page 자체가 팝업되고 이 안에 Microsoft Sign in 을 할 수 있는 섹션이 보인다. 여기에 Email과 패스워드로 인증을 받으면 VPN 연결이 된다. 만약 MFA를 Azure 에서 설정했을 경우에는 Microsoft Authenticator을 통해서 2번 인증하면 VPN이 연결된다.
이상으로 Cisco AnyConnect와 Azure AD을 SAML로 연동하는 방법에 대해서 살펴보았다.
생각해볼 문제
Disaster Recovery by DNS modification
DR (Disaster Recovery)을 위한 DNS Redirection은 사용할 수 없다. 예를들어 2개의 고객 사이트가 있다고 가정해보자. 각각의 사이트는 Cisco ASA를 가지고 있다. 편의상 두개의 사이트와 ASA를 아래와 같이 정의해보자.
Site1.vpn.com (1.1.1.1)
Site2.vpn.com (2.2.2.2)
만약 Site1에 네트워크 장애가 생길 경우, Site1.vpn.com 의 IP 주소를 1.1.1.1에서 2.2.2.2로 DNS 변경을 해주어도 SAML Metadata가 다르기 때문에 단순 DNS 변경으로 DR을 할 수 없게 된다는 것도 생각해 보아야 한다.
Force re-authentication
Cisco AnyConnect Profile이 한개가 아닌 여러개인 경우이면서 동시에 유저가 여러개의 Profile을 사용할 수 있는 권한이 있을 경우 Force re-authentication을 옵션을 넣어두는 것을 추천한다. 그 이유는 처음 Authentication할 때 사용된 Cookie를 컴퓨터가 기억하고 있는 경우, 유저가 여러개의 Profile 중 자신이 원하는 프로파일을 선택할 수 없고 이전 세션을 기억했다가 바로 연결을 하기 때문이다. Force re-authentication을 설정할 경우, 이전 세션을 기억하지 않기에 VPN 로그인 시, 자신이 원하는 프로파일을 선택할 수 있다. 다만, 매번 VPN을 연결하기 위해서 Azure portal에 로그인해야하는 단점도 있다.
'미국 IT 이야기' 카테고리의 다른 글
| Cisco ISR 4451 Router을 이용한 Azure ExpressRoute Private Peering (0) | 2022.08.02 |
|---|---|
| 미국 회사로부터 학비 지원받기 (미국 IT이야기 18) (2) | 2022.07.15 |
| Microsoft 자격증 무료로 취득하기 (미국 IT이야기 17) (0) | 2022.06.14 |
| Azure File Share을 이용한 Network File Share 비용 절감 (0) | 2022.05.31 |
| AWS Summit Washington D.C. 2022 후기 (미국 IT이야기 16) (0) | 2022.05.24 |
