데브옵스 파이프라인의 보안

설계부터 배포에 이르는 소프트웨어 개발 및 DevOps 프로세스에서 보안은 항상 최우선으로 고려해야 합니다. 보안을 뒷전으로 미루면 보안 인시던트가 다시 찾아올 수 있습니다.

이 글에서는 GraphQL API 개발자들이 흔히 저지르는 실수 중 하나, 즉 프로덕션 환경에서 인트로스펙션 기능을 활성화하는 문제를 다뤄보려고 합니다. 인트로스펙션은 개발 단계에서 API 기능을 이해하고 테스트하는 데 매우 유용한 기능입니다. 하지만 라이브 서비스 전에 이 기능을 비활성화하지 않으면 애플리케이션이 심각한 취약점에 노출될 수 있습니다. 이것이 어떻게 주요 보안 위험으로 확대될 수 있는지, 그리고 DevOps 파이프라인에서 보안을 강화하기 위해 취할 수 있는 예방 조치에 대해 설명합니다.

시나리오

조직의 GraphQL API 구현을 주도하는 개발팀을 상상해 보세요. GraphQL은 클라이언트가 한 번의 쿼리로 필요한 것을 정확하게 요청할 수 있도록 설계된 강력한 쿼리 언어입니다. 이는 복잡한 데이터와 관계를 조합하기 위해 여러 요청을 해야 하는 기존의 REST API와는 다릅니다. GraphQL의 데이터 구조는 사용 가능한 데이터 유형, 쿼리 및 변형을 간략하게 설명하는 스키마에 정의되어 있습니다.

개발팀은 엄청난 노력을 기울여 매우 인상적인 것을 구축했습니다. 개발팀이 설계하고 구축한 자동 확장 기능 덕분에 이 API는 견고할 뿐만 아니라 분당 수백만 건의 트랜잭션을 처리할 수 있을 정도로 확장성이 뛰어납니다. 성능과 확장성에 중점을 두어 이 API가 큰 부하를 아무런 문제 없이 처리할 수 있도록 만들었습니다.

하지만 이 반짝이는 새 GraphQL API를 서둘러 배포하고 깊은 인상을 남기려다 보니 프로덕션 환경에서는 인트로스펙션이 여전히 활성화되어 있다는 작은 세부 사항을 간과했습니다. 인트로스펙션은 개발자를 위한 강력한 도구로, API에서 어떤 리소스를 사용할 수 있는지 쿼리할 수 있는 방법을 제공합니다. 다만 프로덕션 환경에서 액세스하도록 개방해서는 안 됩니다.

결과는 어떻게 되나요?

API가 수요를 충족하기 위해 확장됨에 따라 새로운 인스턴스가 추가될 때마다 잠재적 위험은 배가됩니다. 이제 심각한 보안 취약점이 점점 더 많은 노드에 확산되고 있습니다. 이로 인해 악의적인 공격자들이 악용할 수 있는 여지가 생겼습니다. 이 새로운 API의 구조와 기능에 대한 자세한 정보를 알아내는 데 필요한 모든 것을 갖추고 있습니다.

팀은 간단한 토글을 잊어버림으로써 선의의 기능을 치명적인 보안 결함으로 만들었습니다.

취약점 이해

인트로스펙션이 활성화되면 개발자는 GraphQL API를 쿼리하여 모든 데이터 유형, 필드, 쿼리 및 변형을 포함한 전체 스키마를 확인할 수 있습니다. 이는 API의 모든 운영 엔드포인트와 데이터 구조에 대한 상세한 지도를 확보한 것과 같습니다. 개발자에게는 매우 유용한 리소스입니다. 하지만 사이버 공격자의 손에 들어가고 싶지는 않을 것입니다.

공격자가 어떻게 인트로스펙션 기능을 악용하여 GraphQL API에 대해 알아낼 수 있는지 생각해 보세요. 먼저, 공격자는 쿼리 결과를 읽기 쉽게 만들기 위해 조각을 정의할 수 있습니다.

fragment FullType on __Type {     kind     name     description     fields(includeDeprecated: true) {       name       description       args {         ...InputValue       }       type {         ...TypeRef       }       isDeprecated       deprecationReason     }     inputFields {       ...InputValue     }     interfaces {       ...TypeRef     }     enumValues(includeDeprecated: true) {       name       description       isDeprecated       deprecationReason     }     possibleTypes {       ...TypeRef     }   }   fragment InputValue on __InputValue {     name     description     type { ...TypeRef }     defaultValue   }   fragment TypeRef on __Type {     kind     name     ofType {       kind       name       ofType {         kind         name         ofType {           kind           name           ofType {             kind             name             ofType {               kind               name               ofType {                 kind                 name                 ofType {                   kind                   name                 }               }             }           }         }       }     }   }

그런 다음 쿼리를 전송하여 __schema 필드에서 쿼리의 루트 유형에서 사용할 수 있습니다. GraphQL 쿼리는 다음과 같이 보일 수 있습니다:

{   __schema {     queryType {       name     }     mutationType {       name     }     subscriptionType {       name     }     types {       ...FullType     }     directives {       name       description       locations       args {         ...InputValue       }     }   } }

공격자는 해당 쿼리를 조각 정의와 함께 인트로스펙션이 활성화된 GraphQL API로 보내면 모든 API 세부 정보가 포함된 포괄적인 JSON 객체가 포함된 응답을 받게 됩니다. 그런 다음 GraphQL Voyager와 같은 도구를 사용하여 GraphQL API를 대화형 그래프로 표시할 수 있습니다.

다음은 위에서 보여드린 인트로스펙션 쿼리에 대한 응답을 기반으로 한 GraphQL API의 시각화 예시입니다:

보시다시피, 민감한 결제 작업과 관련된 많은 구조와 세부 정보를 확인할 수 있습니다. 이는 API에 침투하려는 공격자에게 매우 유용한 정보입니다. 다시 말하지만, 개발자에게도 좋지만 안타깝게도 공격자에게도 좋은 정보입니다.

프로덕션 환경에서 인트로스펙션을 사용하도록 설정하면 다음과 같은 위험에 직면할 수 있습니다:

• 정보 노출: 상세한 스키마 정보는 공격자에게 백엔드 시스템, 데이터 모델, 비즈니스 로직에 대한 인사이트를 제공할 수 있습니다. 공격자에게 성에 대한 청사진을 넘겨주면 공격자가 표적 공격을 쉽게 할 수 있습니다.
• 공격의 용이성: 공격자는 API에 대한 이러한 세부 정보로 무장하여 취약점을 악용하는 쿼리를 만들 수 있습니다. 이는 데이터 유출 또는 서비스 중단으로 이어질 수 있습니다.
• 리소스 낭비: 공격자는 이러한 지식을 이용해 서비스 거부(DoS) 공격으로 악의적인 쿼리를 만들 수도 있습니다. 이러한 공격은 리소스를 소모하여 시스템을 완전히 다운시킬 수 있습니다.

하지만 절망하지 마세요! 이러한 위험을 완화하는 단계는 간단하고 간단합니다. 스스로를 보호하기 위한 첫 번째 단계로 OWASP의 의견을 살펴봅시다.

OWASP GraphQL 치트 시트의 지침

OWASP GraphQL 치트 시트는 GraphQL API를 보호하는 데 유용한 리소스입니다. 다음 영역에 도움이 되는 지침을 제공합니다:

• 입력 유효성 검사
• 고비용 쿼리 제한 또는 방지
• 적절한 액세스 제어 확인 보장
• 인트로스펙션과 같은 안전하지 않은 구성 비활성화하기

치트 시트에는 인트로스펙션과 GraphiQL에 대한 섹션이 있습니다. GraphiQL은 GraphQL을 탐색하기 위한 브라우저 내 IDE입니다. 인트로스펙션 기능과 마찬가지로 GraphiQL은 API의 내부 작동 및 디자인에 대한 자세한 정보를 노출할 수 있습니다.

GraphQL API를 구축하는 경우 OWASP 치트 시트를 숙지하는 것이 좋습니다.

인트로스펙션 보안 취약점을 완화하는 방법

OWASP 치트 시트에서 힌트를 얻어 프로덕션 환경이나 공개적으로 액세스할 수 있는 환경에서 인트로스펙션 쿼리를 비활성화하라는 지침에 유의할 것입니다. 이는 공격자가 악용할 수 있는 세부 스키마 정보에 대한 무단 액세스를 방지하는 데 중요한 역할을 합니다.

어떻게 할 수 있을까요?

다음은 Apollo Server를 사용하는 경우 프로덕션 환경에서 인트로스펙션을 해제하는 방법을 보여주는 간단한 JavaScript 코드 스니펫입니다:

const { ApolloServer } = require('apollo-server'); const server = new ApolloServer({   typeDefs,   resolvers,  // Enable introspection only in development or test environments   introspection: process.env.NODE_ENV === 'development' ||                 process.env.NODE_ENV === 'test', }); server.listen().then(({ url }) => {   console.log(`Server ready at ${url}`); });

예, 기본적으로 여기까지입니다. 이 간단한 단계(설정 introspection 에 false 의 새 인스턴스를 구성할 때 ApolloServer)는 사용자가 인트로스펙션 쿼리를 통해 자세한 스키마 정보에 액세스하는 것을 방지합니다. 이렇게 하면 민감한 정보가 유출될 위험이 줄어듭니다.

보안 데브옵스 파이프라인의 일부로 만들기

이 단계가 그렇게 간단한데도 개발자들은 왜 그렇게 자주 잊어버릴까요? 개발자들은 다른 일에 집중하고 중요한 마감일을 맞추느라 바쁘기 때문입니다. 사소해 보이는 구성 설정이 간혹 간과되는 것은 놀라운 일이 아닙니다.

그렇기 때문에 자동화된 테스트와 DevOps 파이프라인을 통해 인적 오류와 건망증을 방지할 수 있습니다.

이 보안 조치를 데브옵스 파이프라인에 어떻게 통합할 수 있을까요? 다음은 두 가지 제안입니다:

• 프로덕션 배포 시 인트로스펙션이 비활성화되도록 GraphQL 서버 구성을 명시적으로 검사하는 배포 전 테스트를 작성하세요.
• 프로덕션 환경에서 인트로스펙션 쿼리를 시도하는 배포 후 테스트를 작성합니다. 시도가 오류 응답(예 Cannot query field '__schema' on type 'Query')를 통과하면 테스트에 합격한 것입니다.

CI/CD 프로세스의 일부로 GraphQL API 설정을 확인하는 스크립트를 실행하려면 Jenkins, GitHub Actions 또는 CircleCI와 같은 CI/CD 파이프라인 도구를 활용하세요.

결론

GraphQL API를 구축하는 것은 회사의 혁신을 위한 좋은 방법이 될 수 있지만, 이를 위해서는 보안 관행에 대한 사전 예방적 조치가 필요합니다. 작은 실수 하나만으로도 API가 큰 취약점에 노출될 수 있습니다. 이 글에서는 프로덕션 배포에 대한 인트로스펙션을 비활성화하여 공격자가 GraphQL 스키마의 세부 정보에 액세스하지 못하도록 하는 것을 대표적인 예로 다루었습니다.

추가 지침과 리소스는 보안, GraphQL 개발과 관련된 Linode의 종합 가이드 라이브러리( https://www.linode.com/docs/guides/platform/)를 참조하세요.