IT의 중심에서

기술은 사람을 행복하게 할 때 가장 아름다워진다.

API key, API 인증과 권한관리

Apigee Webinar “10가지 API 로드맵 고려사항” 중 세번째 글입니다.

API 보안관리에 대해 기술한 다소 기초적인 글입니다.
API 개발경험이 많은 회사도 API를 오픈하려고 하면, API Key 관리를 위해 어떤 기술구조를 가지고 가야 효율적인지 잘 모릅니다.

단순하게는 DB Query를 사용하기도 합니다만, API Response time을 줄이기 위해 memory cache를 많이 사용합니다.
API Key조차도 Authorization, Authentification, LifeCycle mgmt가 필요하기 때문에 이 부분이 같이 엮이면 더 복잡해집니다.

이런 복잡한 이야기들은 차차 할 기회가 있을 것 같습니다.
우선 아래의 간단한 내용들을 먼저 정리합니다.


※ 원문 : Do you need API keys? API Identity vs. Authorization

우리는 완전한 open API 를 가진 API Provider 를 거의 보지 못했다. – 거의 모든 API는 최소한 이런 한가지 사항을 가지고 있다.

  • Identity – who is making an API request?
    아이덴티티 – 누가 API 요청을 하는가?

  • Authentication – are they really are who they say they are?
    인증 – 그들은 정말 그들인가?

  • Authorization – are they allowed to do what they are trying to do?
    권한 – 그들이 하려고 하는 것이 허락되어 있는가?


  • 당신은 그들 모두를 필요로 하는가? 아닐 수도 있다. 어떤 API 는 단지 아이덴티티만 필요하고, 인증이나 권한은 필요하지 않을 수 있다.

    API Identity vs. Authentication – 구글맵과 트위터 비교해보기

    야후나 구글맵을 보자. – 그들은 누가 봐도 오픈되어 있다. 그들은 당신이 누구인지 알고 싶어한다.
    그러나, 그들은 당신이 어떤 주소를 방문하는지는 알고 싶어하지 않는다.
    그래서 그들은 아이덴티티를 확인하기 위해 API key 를 사용한다. 그러나, 인증하거나 권한을 관리하지는 않는다.
    그래서 만일 다른사람의 API key를 사용한다면, 그것은 바람직하지 않지만 심각한 보안 문제도 아니다.

    API key로 누가 API 요청을 하는지 알기 때문에 request 수에 제한을 걸 수가 있다.
    아이덴티티는 Service Volumn을 통제하기 위해 매우 중요하다.

    그러면, 트위터 API 를 보자.
    사용자가 공개한 정보를 찾기 위해 오픈되어 있다. 그러나 다른 작업들은 권한을 필요로 한다.
    그래서, 트위터는 사용자와 암호를 통한 인증과 OAuth 인증을 둘 다 제공한다.
    트위터는 그 코드안에 인증코드를 가지고 있다. 그래서 당신은 그들의 패스워드나 계정에 대한 OAuth 없이 다른 이들 대신 트윗할 수 없다.
    이것이 식별(Identify)하고, 인증(Authentification)과 권한(Authorization)을 보여주는 사례이다.

    The “API Key” – do you need one?

    API key 는 야후나 구글 API 처럼 웹서비스로부터 비롯되었다.
    개발자들은 암호를가지고 사용자를 인증하는 복잡한 과정없이 아이덴티티를 확인하는 방법을 원했다.
    그래서 API key 라는 것을 만들었다. 때로는 UUID나 unique string 이기도 했다.
    API key가 매우 민감한 데이터에 대한 접근권한을 주지 않는다면, 보안에 민감하지 않을 것이다. 이러한 API key 사용법은 API 소비자가 다양한 API 호출방법을 쉽게 만들었다.

    API key는 API provider 가 각 호출자가 로그를 남기고, 사용자별로 쿼타를 줄 수 있게 아이덴티티를 알수 있게 하는 방법을 제공하는 것이다.

    Usernames and Passwords – again, see Twitter

    훨씬 더 민감한 데이터라면 간단하다. 만일 사용자가 key를 안전하게 관리하는지 확인할 수 없다면, API key 는 충분하지 않다.
    대체수단은 유저아이디와 암호인증이다. 대부분의 secure 웹사이트에 의해 지원되는 권한관리 같이!

    대부분의 웹사이트에서 사용하는 http basic 인증을 사용하는 것이 가장 쉽다.
    이 기술의 잇점은 거의 모든 클라이언트와 서버가 그 방식을 지원한다는 것이다. 특별한 프로세스가 요구되어지지도 않는다. 호출자가 암호관리에 주의를 충분히 기울이는 한 말이다.
    유저가 트위터 클라이언트를 시작할 때마다, 유저아이디와 암호를 묻고 disk 로부터 읽어들인다. (다소 암호화되어 있을 수 있다.) 그래서, 트위터 API가 웹사이트처럼 유저아이디와 암호를 가지는 것은 합리적인다.

    유저아이디와 암호는 어플-어플간의 커뮤니케이션에 잘 작동한다.
    암호는 더 신중하게 저장되어야 한다. 만일 서버에 의해 사용되어지고 나면, 어디에 저장되어져야 하는가?
    만일 당신이 DB 를 사용하는 서버를 운영하고 있다면, 당신은 이미 동일한 문제를 풀었을 것이다. 왜냐하면, DB 도 통상적으로 암호를 사용하기 때문이다. 더 좋은 어플리케이션 서버플랫폼은 상대적으로 안전하게 암호를 저장할 수 있는 ‘credential mapper’를 가지고 있다.

    Session-based Authentication – cumbersome with RESTful APIs

    많은 API 들이 세션 기반의 인증을 제공한다. 이 구조에서는, 사용자는 처음에 login method를 호출해야만 한다. 그리고, 유저아이디와 암호를 입력받고, 고유의 세션키를 리턴한다.
    유저는 각 request 마다 세션키를 포함해야만 한다. 그리고, 일이 끄나면 logout 을 호출한다.
    이 방법에서 인증은 한 쌍의 API call 에 의해 수행되어진다. 그리고, 그 밖의 모든 것은 세션에 기반해서 수행된다.

    이런 종류의 인증은 매우 자연스럽게 웹사이트에 매핑되어진다. 왜냐하면, 사용자들은 특정 사이트에 접속하면, 습관적으로 log in 하고 일이 끝나면 log out 하기 때문이다.
    그러나, 세션 기반의 인증은 API 와 관련되어질 때 매우 복잡해진다. 그것인 API client 가 상태를 지속시키고, 힘들고 불가능한 어떤 client 유형에 의존적일 것을 요구한다.
    세션 기반이 인증은 당신의 API를 보다 덜 RESTful 하게 한다. – API client 는 단순히 하나의 http request 를 만드는게 아니라, 최소 세 개의 http request 만든다.

    Two-Way SSL, X.509, SAML, WS-Security…

    일단, 우리가 평범한 http 의 세상을 떠난다면, 우리는 SAML, X.509 인증, 양방향 SSL 등 수많은 인증 method를 만나게 된다. 그것들은 개별 client 와 다양한 WS-Security specifications 에 대한 public key 의 안전한 배포를 보장한다. 그리고, SOAP 상에서 만들어지기도 한다. 음. 모든 것에 대해 적용이 가능핟.

    API 는 원칙적으로 기업형 고객들에 의해 사용되어진다. – 즉, 큰 IT 기업들 – 그들은 X.509인증서나, 단순한 아이디/암호 인증 프로세스보다 더 많은 안정성을 보장하는 SAML류의 매커니즘을 고려하기도 한다.
    그리고, 큰 기업들은 SOAP 표준에서 만들어진 API 에 접근하는게 더 쉽기도 하다. 왜냐하면, 그런 도구들은 WSDL 파일을 import 하고, 몇 분만에 API client 를 만들수도 있기 때문이다.

    Know your audience.

    만일 당신의 고객이 SOAP 이나 WSDL 의 팬이라면, 더욱 더 SAML 이나 WS-security specifications 과 같은 SOAP 틱한 인증에 대해 고민해보라. (만일 당신이 내가 말하는 것을 이해하지 못한다면, 당신의 고객은 아마도 해당사항이 없을 수 있다.)

    SSL

    대부분의 인증 파라미터는 불필요하다. 또는 심지어 위험할 수도 있다. “SSL이 없다면 말이다.”
    예를 들어 http basic 인증에서 API 는 client 가 사용하는 암호를 보아야만 한다. 그래서 암호는 base64로 인코딩되어 있다. – 그러나 암호화되어 있지는 않다. 식별가능한 암호로 되돌리는 것은 매우 쉬운일이다.
    해독제는 client와 server 사이에 전송되는 모든 것을 암호화하기 위해 SSL을 사용하는 것이다.
    이것은 통상적으로 사용하기 쉽고, 사람들이 생각하는 만큼 성능 감소가 많지 않다. (apigee 제품의 경우, throughput이 10~15% 정도 감소되었다.)

    OAuth와 같은 security 구조들은 도청 보안 등을 고려해서 만들어졌다. 예를 들면, OAuth 는 각 request 에 대해 ‘일회용 키’를 포함한다. 그래서 하나의 request 상에서 OAuth 토큰을 가로채더라도 다음에는 그것을 사용할 수 없게 된다. 물론 request 상에서 민감한 정보들에 대해서도 그렇다.
    일반적으로, 만일 당신의 API 가 SSL 을 사용하지 않는다면, 잠재적으로는 API 가 하는 모든 일이 노출될 수 있다.

    So Many Authentication Schemes – What Should You Use?

    OAuth, OpenID, SAML, HTTP authentication, WS-Security, and the basic API key – 수많은 API 많큼 수만은 인증 scheme들이 있다. 언제 무엇을 사용할 것인가?

    추천을 바란다면, 계속 구독해주세요.

    답글 남기기

    아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

    WordPress.com 로고

    WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    Twitter 사진

    Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    Facebook 사진

    Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    Google+ photo

    Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    %s에 연결하는 중

    정보

    이 엔트리는 2012년 3월 5일에 님이 API와 기술에 게시하였으며 , , , , 태그가 지정되었습니다.

    내비게이션

    누적 조회수

    • 930,545 Visits

    페이스북 페이지

    %d 블로거가 이것을 좋아합니다: