Offcanvas

보안

로우코드·노코드 전사 도입 시 고려해야 할 10가지 보안 정책

2023.12.11 Ericka Chickowski  |  CSO
로우코드/노코드 플랫폼은 전문 IT 인력이 없이도 훌륭한 아이디어와 구체화하는 데 도움을 준다. 하지만 액세스 제어, 코드 품질, 애플리케이션 가시성과 같은 영역에 대한 보안 정책이 함께 뒷받침되어야만 의미 있는 결과를 만들 수 있다.
 
ⓒ Getty Images Bank

로우코드 개발 플랫폼은 개발자와 비 개발자 모두에게 유용하다. 전문 개발자가 로우코드 개발 플랫폼을 사용하면 개발 주기를 단축할 수 있다. 비 개발자이자 비즈니스 사용자의 경우 작업을 자동화하는 애플리케이션을 빠르게 만들거나, 기존 애플리케이션을 서로 연결하거나, 필요에 따라 정확하게 작동하도록 소프트웨어를 사용자 지정할 수 있는 시민 개발자로서의 역량을 키울 수 있다. 

하지만 로우코드 개발 플랫폼을 제대로 이용하려면 보안 영역을 더 철저히 신경써야 한다. 적절한 보안 정책과 제어 메커니즘이 없다면 로우코드/노코드는 기존의 애플리케이션 보안 문제를 악화시키고 액세스 제어, 코드 품질, 애플리케이션 가시성 관련 보안 문제를 야기시킬 수 있기 때문이다. 이런 이야기를 들을 때면 기업 내부에서 로우코드/노코드 개발을 전면적으로 금지하고 싶은 마음이 들 수 있다. 하지만 로우코드/노코드 보안 회사인 제니티(Zenity)의 공동 설립자 겸 CTO인 마이클 발구리(Michael Bargury)는 “보안 때문에 로우코드/노코드를 막을 수 있는 CISO는 없다”라고 표현했다. 

발구리는 “로우코드/노코드 트렌드를 거스를 수는 없다”라며 “일부 조직에서 '로우코드와 노코드는 허용하지 않겠다'고 말하거나 '허용하겠지만 이 플랫폼에서만 허용하겠다'고 말하는 것을 볼 수 있다. 보안 리더 입장에서 시도를 해볼 수 있겠지만 이러한 접근 방식은 몇 년 전 사내에 개인 기기 사용을 금지했던 것만큼 실효성이 있지 않다”라고 설명했다.

완전한 금지 대신 발구리는 보안성을 높이기 위해 로우코드/노코드 개발관련 정책을 수립하고 이러한 개발 환경에서 가장 큰 위험을 관리할 수 있는 적절한 프로세스와 기술을 구축할 것을 제안했다. 다음은 실제로 보안 리더가 로우코드/노코드 도입할 때 고려하면 좋은 10가지 정책이다.

1. 허용 가능한 사용 사례 목적 및 범위 정책
여느 보안 정책과 마찬가지로 조직은 특정 보안 정책을 정의하고 시행하기 전 미리 현재 상황을 감사하고 문서화를 해 놓는 것이 좋다. 전문 개발자와 비즈니스 사용자가 사내에서 로우코드 및 노코드 기술을 어떻게 활용하고 있는지 평가하고 깊이 파고들어야 하는 것이다. 

발구리는 많은 CISO와 기술 리더들이 로우코드와 노코드가 오늘날 환경에 이미 얼마나 널리 퍼져 있는지 깨닫지 못하고 있다고 경고했다. 평가 과정에서는 유명한 엔터프라이즈급 노코드/로우코드 플랫폼뿐만 아니라 기술에 정통한 비즈니스 사용자가 IT 영역 밖에서 이용할 수 있는 기술에 대해서도 살펴봐야 한다. 전통적 SaaS 및 소프트웨어 플랫폼 공급업체도 찾아보면 좋다. 개발팀의 도움 없이도 사용자가 커넥터를 맞춤화하고 추가할 수 있도록 노코드/로우코드 기능을 제공하는 서비스가 많기 때문이다. 

중요한 것은 평가를 철저히 한 다음 기존 사용 사례를 문서화하고 정의하는 것이다. 특정 사용자 그룹이 현재 특정 로우코드/노코드 플랫폼을 활용하는 이유를 이해하면 보안 및 비즈니스 리더가 향후 정책 방향을 결정하기 위한 리스크를 파악하는데도 도움을 받을 수 있다. 

이런 작업을 통해 결국 리더는 비즈니스 전반에 걸쳐 로우코드/노코드에 대해 허용 가능한 사용 사례를 정의하는 정책을 마련할 수 있다. 

개발 컨설팅 회사인 테크어헤드(TechAhead)의 CEO인 비카스 카우식(Vikas Kaushik)은 “부서 전체에 로우코드 및 노코드 개발의 적용 범위를 지정하고, 로우코드 및 노코드 개발의 목적을 명확히 명시해야 한다”라며 설명했다. 이러한 목적과 범위의 정책은 사용 사례와 관련된 위험 관리 정책의 방향성을 설정하는 데 매우 중요하다. 

일부 기업은 비즈니스 라인, 비즈니스 기능, 사용자 그룹 또는 팀별로 세분화하여 매우 세분화된 정책을 선택할 수 있다. 단순히 전문 개발자와 기술에 정통한 비즈니스 이해관계자, 이른바 시민 개발자를 구분해 볼 수도 있다. 

2. 플랫폼 실사 정책
로우코드/노코드 플랫폼 또는 SaaS 확장 프로그램은 기능의 차이 외에도 보안의 성숙도 영역에서 차이가 있다. 

보안 기업 깃가디언(GitGuardian)의 보안 전문가인 토마스 세구라(Thomas Segura)는 “현재 출시된 로우코드 플랫폼의 보안 성숙도는 기껏해야 초기 단계에 불과하다”라며 “많은 플랫폼에는 엄격한 규정과 표준을 준수하는 데 필요한 강력한 보안 기능이 기본적으로 포함되어 있지 않다. 특히 정교한 데이터 거버넌스 도구, 포괄적인 감사 추적, 민감한 정보를 적절히 보호하는 데 필요한 암호화 표준이 부족한 경우가 많다. 보안 성숙도가 충분히 높지 않기 때문에 조직은 관련 플랫폼을 도입할 때 보안 및 규정 준수를 강화하기 위한 추가 조치를 취해야 한다”라고 조언했다. 

조직이 특히 시급히 마련해야 하는 정책은 사용을 승인하기 전에 플랫폼에 대해 어떤 종류의 심사를 얼마나 많이 수행할 것인가 하는 것이다. 이를 통해 각 플랫폼의 보안 수준을 파악하고 기준선을 두고 도입할 가치가 있는지 결정할 수 있다. 

평가 정책에는 조직이 플랫폼의 보안 기능 및 규정 준수 제어뿐만 아니라 플랫폼 자체의 보안 태세도 검토하도록 규정해야 한다. 여기에는 문서를 요청하고 잠재적으로 침투 테스트를 수행할 수 있는 권한을 요청하는 것이 포함될 수 있다고 보안 컨설턴트이자 스택어웨어(StackAware)의 설립자인 월터 헤이독(Walter Haydock)이 설명했다. 헤이독은 최근 개발 작업에 여러 로우코드 플랫폼을 활용하고 있으며, 사용하는 플랫폼의 보안 수준을 점검하고 있다. 

헤이독은 “예를 들어 노코드 플랫폼 버블(Bubble)은 침투 테스트 수행 방법에 대한 정책을 구체적으로 명시하고 있다”라며 “나는 제노(Xano)라는 플랫폼을 이용하고 있으며, 제노는 ISO 27001 인증을 받았다. 그 말은 보안 프로그램에 대한 공식적인 감사를 받았으며, 하위 프로세스와 기술 스택 등의 측면에서 매우 투명하다는 뜻이다. 그래서 이런 기술을 보다 자신 있게 이용하고 있다”라고 밝혔다. 

깃가디언의 세구라는 또한, 보안팀은 플랫폼과 플랫폼에서 생성되는 애플리케이션이 민감한 데이터를 처리하는 방식과 플랫폼이 기존 보안 제어와 얼마나 잘 작동하는지에 대한 평가를 공식화해야 한다고 조언했다. 

세구라는 “조직은 데이터 및 PII 확산을 방지하기 위해 도입을 고려하는 모든 플랫폼에 대해 엄격한 보안 실사를 수행하여 이러한 플랫폼이 기존 보안 인프라와 원활하게 통합될 수 있는지 확인해야 한다”라며 “필요한 경우, 데이터에 대한 완전한 제어권을 유지하기 위해 셀프 호스팅 솔루션을 우선적으로 고려해야 한다”라고 설명했다. 

3. 허용 가능한 플랫폼 개수 정책
사용 사례를 정의하고 현재 사용 중인 플랫폼을 검토했다면 이제 특정 사용 사례를 지원하는 데 가장 적합한 노코드/로우코드 플랫폼을 결정해야 한다. 이때 사용 중인 플랫폼이 많을수록 플랫폼과 플랫폼에서 흘러나오는 애플리케이션 내부 위험을 관리하기가 더 어려워진다. 따라서 보안의 관점에서 볼 때 허용 가능한 플랫폼 목록을 간결하게 유지하는 것이 이상적이다.

세구라는 “조직은 이러한 위험을 효과적으로 관리하기 위해 로우코드 애플리케이션의 개발과 배포를 중앙 집중화하는 정책을 구현해야 한다”라고 조언했다. 세구라는 스스로 내부 및 외부 규정 준수 요건을 가장 잘 충족하는 단일 플랫폼을 선택하는 정책을 선호하고 있다. 세구라는 “이런 정책은 섀도 IT의 위험을 완화하고, 일관된 보안 관행을 보장하며, 규정 준수 프로세스를 간소화할 수 있다”라고 밝혔다. 

하지만 발구리의 생각은 다르다. 그는 조직에서 단일 플랫폼(일부 대기업의 경우 2~3개)을 이용할 경우 다양한 그룹과 비즈니스 이해관계자의 모든 사용 사례의 요구 사항을 충족하기 쉽지 않다는 의견을 냈다. 대신 그는 리스크에 적합한 방식으로 사용자 요구를 충족하는 데 초점을 맞춘 포트폴리오 접근 방식을 취할 것을 권장했다. 현재 사용량과 비즈니스 요구 사항을 기반으로 몇 가지 플랫폼을 선택하고 개발 및 보안 지원을 해당 플랫폼에 집중하자는 것이다. 

그다음에는 보안 엔지니어가 시민 개발자와 전문 개발자 모두에게 해당 플랫폼을 사용하는 데 있어 안전한 길을 선택하도록 ‘포장된 길’, 즉 가이드라인을 제공해야 한다. 이를 위해서는 플랫폼에 대한 정책 작업, 구성 작업, 사용자 지정 및 제어가 필요하다. 또한 핵심 사용 사례의 요구사항을 충족하면서도 가장 적은 양의 작업을 필요는 플랫폼을 선택하면 좋다.

이러한 정책의 일환으로 조직은 일반 소프트웨어 플랫폼 또는 SaaS 제품 내에서 임베디드 또는 애드온 로우코드/노코드 기능을 활성화해도 되는 경우와 보안팀이 이러한 확장 기능을 비활성화할 경우를 정의해야 한다. 가령 코드가 필요 없는 규칙 자동화 도구인 세일즈포스의 비즈니스 규칙 엔진과 같은 도구를 비즈니스에서 실행하도록 허용해도 될까? 정책은 이러한 종류의 질문에 대한 명확한 답변을 제공해야 한다.

4. 환경 사양 정책
발구리는 보안 리스크를 줄이기 위해 프로 개발자와 비즈니스 코더를 위한 별도의 환경을 규정하라고 조언했다. 프로 개발자가 개발 작업 속도를 높이기 위해 로우코드 툴을 사용하는 경우에도 제품은 안전한 개발 수명 주기를 통해 실행되어야 한다. 발구리는 “개발 라이프사이클의 중요한 지점에서 보안 및 품질 게이트를 설정하기 위해 보안 정책과 절차를 수립해야 한다”라며 “개발자가 로우코드 플랫폼에서 만드는 결과물을 중심으로 런타임 모니터링 및 기타 제어 기능을 사용해야 한다”라고 말했다. 

한편, 시민 개발자의 노코드 작업에 대해서 기업은 보다 관대하게 접근할 수 있다. 대신 시민개발자가 제어할 수 있는 영역을 명확히 구분해 두어야 한다. 발구리는 “시민 개발자를 위한 공간을 나눠 놓자. 모든 사람이 같은 공간에서 구축하도록 하면 재앙을 초래할 수 있다”라며 “사용 사례에 따라 환경을 구획화하면 좋다”라고 조언했다. 

5. 위험 경계 정책
사용 사례에 따라 환경을 세분화하면 로우코드/노코드 앱이 실제로 실행된 후 어떤 기능과 방식으로 작동하는지에 따라 위험 경계 정책을 수립하는 데 도움이 될 수도 있다. 발구리에 따르면 오늘날 성공적인 조직 상당수가 애플리케이션을 구축하는 데 관대한 접근 방식을 취하다가 문제가 드러나면 통제를 강화하는 방식을 취하고 있다.

발구리는 “처음엔 모든 사람이 큰 장벽 없이 애플리케이션을 구축할 수 있는 환경을 조성하지만, 애플리케이션이 민감한 데이터에 닿거나 10명 이상의 사용자와 공유되면 앱 설정 관련 권한을 조정을 할 수 있게 만들 수 있다”라며 “특정 경계를 넘으면 ‘경계를 넘었습니다’라는 이메일을 주는 식이다. 또는 인프라를 다른 환경으로 옮기는 대신 보안 인식 교육을 실시할 수 있다”라고 설명했다. 

보안 인식 교육 외에도 비즈니스 코더가 프로 개발자와 짝을 이루어 앱을 강화하고 경우에 따라 리팩토링까지 해야 할 때도 있다. 이때 노코드 프로세스를 사용해 볼 수 있다. 특정 변수가 트리거되면 앱을 조정하는 것이다. 단 이런 작업을 수행하려면 조직은 먼저 정책 프레임워크에 모든 트리거와 리스크 관련 조건을 파악해야 한다.

6. 데이터 거버넌스 정책
조직은 로우코드/노코드 플랫폼과 관련하여 데이터 거버넌스 및 규정 준수에 대해 매우 명확한 정책을 수립하여 규제 기관의 규제를 위반하지 않도록 해야 한다. 무엇보다도 조직은 각 플랫폼이 접근할 수 있는 데이터의 종류를 규정해야 한다.

로우코드/노코드 앱이 민감한 데이터에 접근할 수 있고 해당 데이터를 통과시키는 앱을 만들 수 있다면, 조직은 모든 것을 규정 준수에 적합한 방식으로 추적할 수 있는 데이터 거버넌스 정책과 통제 장치를 마련해야 한다고 세구라는 경고했다.

세구라는 “로우코드/노코드 솔루션의 분산된 특성으로 인해 민감한 정보를 추적하고 보호하기가 더 어려워지기 때문에 개인 식별 정보와 기밀 데이터가 여러 플랫폼에 분산되면 이후 문제가 생긴다”라며 “결과적으로 조직은 데이터 무결성과 기밀성을 유지하는 데 어려움을 겪고 있으며, 이는 사이버 보안 위협을 가져올 수 있다”라고 설명했다. 

EFS의 클라우드 보안 및 데브옵스 컨설턴트인 유세프 엘 아합(Youssef El Achab)은 “이미 강력한 내장형 보안 제어 기능을 갖추고 있더라도, 로우코드/노코드 플랫폼은 SOC 2 또는 ISO 27000 준수를 위한 내부 요건은 물론 GDPR, HIPAA, CCPA에 명시된 데이터 프라이버시 및 데이터 보안 요건을 충족하기 위해 추가적인 보안 또는 규정 준수 도구 제어 기능이 필요할 수 있다”라고 설명했다. 

엘 아합은 “일부 플랫폼은 암호화, 역할 기반 액세스 제어, 감사 추적을 제공하여 위험을 완화하는 데 도움이 될 수 있는 고급 기능을 제공한다. 하지만 이러한 기능이 모든 규정 준수 요구 사항을 충족하지 못할 수 있으며, 조직은 특정 요구 사항에 따라 이러한 기능을 구성하고 맞춤화해야 한다”라며 “조직은 사용자 데이터를 제대로 처리하지 않거나, 적절한 동의 메커니즘을 제공하지 않거나, 처리 활동의 기록을 유지하지 않을 수 있다. 이는 규제에 따른 벌금과 평판 손상을 초래할 수 있다”라고 설명했다. 

이때 데이터 거버넌스 정책에 따라 추가 조치를 취해야 하는 시기가 결정되기도 한다. 

7. 코드 테스트 정책
조직은 사용 사례와 플랫폼을 정의할 때, 발구리가 언급한 각 ‘포장된 도로’를 따라 생성되는 앱의 종류에 따라 문서화된 코드 테스트 정책을 만들어야 한다. 더 위험한 사용 사례일수록 더 많은 테스트 절차가 필요하며, 프로덕션 단계에 도달하는 로우코드 앱에 대한 정기적인 침투 테스트도 필요할 수 있다. 

컨트라스트 시큐리티(Contrast Security)의 공동 설립자이자 CTO인 제프 윌리엄스(Jeff Williams)는 “조직은 로우코드/노코드 애플리케이션과 API에 대해 기존의 사용자 지정 코드 소프트웨어에 대해 수행하는 것과 동일한 종류의 보안 테스트를 반드시 수행해야 한다”라며 “로우코드/노코드 앱에서도 OWASP 상위 10개의 취약점이 충분히 발생할 수 있다”라고 밝혔다. 

윌리엄스에 따르면, 로우코드/노코드 앱은 모든 플랫폼과 사용 사례에 걸쳐 통합 보안 테스트를 실행할 수 있는 간편한 방식이 없다는 것이 문제다. 그래서 그는 보안 정책과 테스트 절차는 이미 많은 최신 데브섹옵스 작업에 스며든 가드레일 사고방식으로 개발되어야 한다고 조언했다. 

일부 로우코드/노코드 플랫폼에는 초보적인 테스트 또는 제어 기능이 포함될 수 있으며, 이러한 기능은 사용자가 기본적으로 사용할 수 있도록 정책에 명시해야 한다. 하지만 이러한 방식으로는 충분한 수준의 보안성을 확보할 수 없다. 발구리는 보안 및 엔지니어링 팀이 보안 코드와 기능 표준을 자동으로 테스트하고 시행하는 메커니즘을 구축해야 한다고 강조했다.

발구리는 “올바른 선택을 쉽게 할 수 있도록 해야 한다”라며 “자동화된 가드레일이 있어야 하고, 누군가가 도와줘야 하며, 쉬워야 한다. 실수하기 어렵게 만들어야 한다”라고 설명했다. 

8. 접근 제어 정책
이상적으로 기업은 처음부터 직무 및 직원별로 접근 권한을 제어할 수 있는 로우코드/노코드 플랫폼을 도입하는 게 좋다. 하지만 그런 여건을 갖출 수 없다면 보안 정책을 두고 로우코드/노코드 애플리케이션 환경에서의 액세스 제어, 권한 및 비밀 관리에 대한 요구 사항을 정의할 수 있다. 

앱돔(Appdome)의 CPO인 크리스 로클은 “여기에는 보안 제어 설정, 앱 빌드, 앱 서명, 시스템의 관리 및 감사 역할이 포함되어야 한다”라고 설명했다. 그런 면에서 조직은 강력한 액세스 제어를 쉽게 설정할 수 있는 플랫폼을 선택해야 한다. 

헤이독은 시민 개발자가 만든 애플리케이션 내 권한 계층 구조에 대한 명확한 가이드라인을 마련해라고 조언했다. 헤이독은 “권한 구조에 대해 생각하고 이를 서면 정책으로 문서화하는 것이 가장 좋은 방법이지만, 코드(및 기본 구성)에도 문서화하여 해당 정책을 최대한 준수하도록 강제하는 것이 좋다”라며 “로우코드/노코드 플랫폼과 애플리케이션에서 토큰과 키 같은 비밀을 관리하는 방법에 대한 정책도 만들고 시행하라”라고 권장했다. 

로우코드/노코드 플랫폼이 앱 간에 자격 증명을 공유하는 방식도 특히 주의 깊게 다뤄야 한다. 발구리가 과거에 수행한 연구에 따르면 좋은 평판을 가진 플랫폼조차도 기본적으로 시민 개발자의 자격 증명을 앱에서 공유하여 생산된 애플리케이션이 역할 기반 액세스 제어를 완전히 우회하는 것으로 나타났다. 이는 거대한 보안 사각지대가 생길 수 있다는 뜻이기도 한다. 따라서 정책, 구성, 집행 제어를 통해 보안성을 높여야 한다. 

9. 코드 소유권 정책
로우코드/노코드 애플리케이션을 적극적으로 쓰다 보면 코드 소유권과 책임 문제가 발생한다. 발구리는 “로우코드/노코드로 만든 앱이 내부적으로 유명해지거나 비즈니스에 중요한 역할을 수행하곤 하지만 처음 앱과 관여된 사람은 다른 직책으로 이동하거나 회사를 떠날 수 있다”라며 “그렇게 되면 아무도 해당 애플리케이션을 관리하지 않기 때문에 엄청난 양의 기술 부채에 시달릴 수 있다”라고 설명했다. 

발구리는 앞서 언급된 다른 모든 정책을 더 잘 시행하려면 로우코드/노코드 환경에서 생산되는 다양한 애플리케이션의 기술 및 비즈니스 수준에서 소유권을 확립하는 정책과 절차를 마련해야 한다고 조언했다. 

발구리는 “사람들은 지금 '이 애플리케이션의 소유자가 누구인가'라는 문제 때문에 많은 어려움을 겪는다”라며 “애플리케이션을 만든 실무자뿐만 아니라 담당했던 상위 리더가 누구였는지도 명확히 해 두어야 한다”라고 설명했다. 

이러한 정책을 시행하고 소유권을 추적하는 것은 새로운 기술적 문제를 가져온다. 기존 개발에서는 엔지니어링 팀이 일반적으로 기록 시스템 역할을 하는 CMDB를 가지고 있기 때문이다. 이러한 종류의 시스템은 다양한 플랫폼에서 제작된 로우코드/노코드 앱으로 구성된 분산된 포트폴리오에는 존재하지 않는다. 그러나 이는 보안뿐만 아니라 품질, 복원력, 오픈소스 라이선스 준수와 같은 다른 문제를 해결하기 위해서도 해결해야 하는 거버넌스 문제다.

10. 비즈니스 사용자의 코드 사용 제한
마지막으로 고려해야 할 정책은 로우코드 개발이 적절한 사용 사례와 그렇지 않은 사용 사례를 명확히 구분하는 것이다. 많은 조직에서 비즈니스 사용자는 코드가 없는 개발에만 사용해야 하며 코드를 취급해서는 안 된다는 정책을 수립한다.

발구리는 “사용자 지정 컴포넌트나 코드가 필요한 작업을 할 때는 비즈니스 사용자가 코드를 다룰 수 없도록 제한해야 한다”라고 조언했다. 
ciokr@idg.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
Sponsored
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.