2019.06.26

로우코드와 노코드 개발에서 신경써야 할 4가지 보안 문제

Maria Korolov | CSO
로우코드(low-code)와 노코드(no-code) 개발의 장점은 새로운 애플리케이션의 배포 속도를 빠르게 하고 기술 지식이 없는 사용자도 애플리케이션을 만들 수 있게 해준다는 점이다. 개념 자체는 오래 전부터 존재했다. 그러나 지금의 모바일 및 웹 앱을 만들기 위한 새로운 클라우드 기반 플랫폼과 마이크로소프트 오피스 365, 구글 G 스위트, 세일즈포스와 같은 플랫폼에 내장된 툴 덕분에 앱 개발 역량을 갖춘 사용자 기반이 계속 확대되고 있다.
 
ⓒ Getty Images Bank 

마켓 앤 마켓(Markets and Markets)에 따르면, 로우코드 개발 플랫폼 시장은 2017년 43억 달러 규모에서 2022년 270억 달러 규모로 성장할 전망이다. 포레스터가 글로벌 IT 및 비즈니스 의사 결정자를 대상으로 실시한 최근 설문에 따르면, 실제로 기업의 84%는 로우코드 개발 플랫폼 또는 툴을 도입했으며, 100% 투자 대비 긍정적인 효과를 거뒀다.

클라우드 업체는 기업에 모든 직원의 데이터 관련 작업을 한눈에 볼 수 있는 시야를 제공하면서 글로벌 액세스 제어와 권한을 구현할 수 있다. 따라서 이런 개발 플랫폼은 많은 면에서 이 플랫폼으로 대체되는 기존 기술에 비해 더 안전하다. 그러나 포레스터 설문 응답자의 59%는 로우코드 플랫폼 도입에서 가장 큰 과제로 보안을 꼽았다.

전문가들이 선정한, 기업에서 고려해야 하는 로우코드 앱과 관련된 4가지 보안 우려 사항은 다음과 같다.


1. 가시성 부족

로우코드와 노코드 개발의 가장 큰 과제 가운데 하나는 기업에서 직원들이 무엇을 만들고 있는지 일일이 파악하기가 어려울 수 있다는 점이다. 주니퍼 네트웍스의 위협 연구 책임자는 모니르 하하드는 섀도우 IT 문제와도 관련된다면서 “대부분의 섀도우 IT는 섀도우 개발과 연계된다. 직원이 회사 IT를 우회해 스토리지든, 컴퓨팅이든, 퍼블릭 클라우드 인프라를 설정해 사용할 때 해당 애플리케이션은 클라우드에서 데이터를 처리하도록 허용하는 경우가 많다”고 지적했다.

온프레미스 로우코드 플랫폼 역시 마찬가지의 가시성 문제를 유발할 수 있다. 예를 들어 마이크로소프트 엑셀 스크립트, 매크로는 기업에서 흔히 사용되지만 거의 통제할 수 없다. 가트너 분석가 제이슨 웡은 “데스크톱에 빠른 애플리케이션 개발 툴을 설치하고 앱을 구축하면 IT 부서는 이를 전혀 볼 수 없다”고 말했다.

웡은 클라우드로의 전환이 시야 개선에 도움이 된다면서 “액세스에 거버넌스를 적용할 수 있는 역량이 더 강화되고 역할 기반 권한을 할당할 수 있다”고 말했다. 덕분에 클라우드 기반 플랫폼은 기존 플랫폼에 비해 더 안전하다.

웡은 세일즈포스 앱 빌더 사용이 허가되지 않은 비즈니스 사용자의 경우를 예로 들면서 “이들은 데이터를 추출해서 엑셀에 입력한다. 이 방식은 세일즈포스에서 앱을 구축하는 것보다 덜 안전하다. 세일즈포스의 경우 시야를 확보하고 어떤 일이 일어나는지 파악할 기회가 있는 반면 여기저기 확산되고 공유되는 액세스 데이터베이스는 그렇지 않다”고 말했다.


2 데이터 감독의 부재

기업이 로우코드와 노코드 플랫폼으로 전환할 때 가장 먼저 확인해야 할 점은 데이터가 안전한지 여부다. 플랫폼에 따라 기업은 공유되는 데이터의 종류 또는 사용되는 방식을 제한할 수 있다. 웡은 “샌드박스를 설정해 사용자가 원하는 것을 자유롭게 만들되 미션 크리티컬 데이터에는 액세스하지 못하도록 할 수 있다. 샌드박스 이외의 부분에 액세스해야 하는 경우 예를 들어 사업부와 IT 부서에 ‘나는 HR 소속이지만 앱에 이 고객 데이터가 꼭 필요하다’고 요청할 수 있다. 그러면 해당 데이터에 대한 읽기 전용 액세스 권한을 승인하는 등의 대처가 가능하다”고 설명했다.

최상위의 엔터프라이즈급 플랫폼 중 상당수는 사업부에 다양한 통제 기회를 제공한다. 웡은 “모든 사람에게 모든 것을 개방하면 안 된다는 것만 이해하면 된다”고 말했다.

케나 시큐리티(Kenna Security)의 수석 보안 엔지니어인 제리 갬블린은 기반 데이터의 보안이 코드보다 더 중요한 우려 사항이라면서 “파이 값을 계산하는 소프트웨어라면 회사에 큰 문제가 되지 않는다. 그러나 이 소프트웨어에 민감한 고객 데이터를 입력한다면 문제가 된다. 즉, 데이터를 먼저 생각해야 한다”고 말했다. 

스렛 스택(Threat Stack)의 엔지니어링 담당 부사장 사빈 토마스는 일부 로우코드 및 노코드 플랫폼의 문제점 중 하나는 종종 최종 사용자가 구성과 권한, 액세스 제어에 관한 의사 결정을 내리는 위치에 있다는 점이라고 말했다. 이런 플랫폼에는 고객 데이터가 격리되고 분할되는 방식에 근본적인 위험이 있다. 토마스는 “효과적인 데이터 분리를 위해서는 액세스 및 역할 정의를 구현해야 하는데, 이 작업은 일반적으로 정작 로우코드 플랫폼의 주된 사용자인 일반 직원 개발자는 할 수 없는 일”이라고 말했다.

토마스는 로우코드 플랫폼마다 세분화된 제어 기능이 다르다고 덧붙였다. 예를 들어 구글 문서 및 기타 협업 플랫폼에는 일반적으로 데이터의 열람과 편집, 공유를 제어하는 액세스 메커니즘이 있다. 토마스는 “그러나 로그인 및 재공유, 시한부 액세스의 자동 만료 및 더 세부적인 액세스 제어가 가능한 고급 통제 역량은 기본적인 기능 범위를 벗어난다”고 말했다.

디지털 자문 서비스 업체인 스파크하운드(Sparkhound)의 비즈니스 자동화 담당 이사인 리처드 살리나스는 일부 로우코드 플랫폼의 경우 사용자가 여러 시스템 및 데이터 소스에 연결되는 애플리케이션을 만들도록 허용한다는 점 역시 문제라고 지적했다. 살리나스는 “모든 데이터 소스에는 자체적인 보안 메커니즘이 있다. 예를 들어 앱이 셰어포인트 사이트에 연결될 때 적용되는 거버넌스와 권한이 적합하지 않는 경우가 있다”고 말했다.

이 경우 엉뚱하게 개발 플랫폼이 보안 문제의 원인으로 지목될 수 있지만 살리나스는 “개발 플랫폼이 아닌 데이터 소스와 데이터 소스 관리자의 문제”라고 말했다.


3. 업체 시스템에 대한 감사의 부재

로우코드 또는 노코드 플랫폼 업체가 구현하는 코드 및 보안 통제 수단은 기업에서 볼 수 없는 경우가 많다. 이런 업체가 얼마나 안전한지 확인하려면 이미 사용 중인 서드파티 보안 감사, 보안 및 규정 준수 인증, 서비스 수준 협약, 사이버 보안 보험과 같은 툴에 의존해야 한다.

한 명의 최종 사용자가 특정 플랫폼을 사용하기로 결정하는 것과 기업이 전사적으로 이 플랫폼을 도입하기로 결정하는 것은 다르다. 갬블린은 “개별 사용자가 SaaS 서비스를 이용할 경우 그 사용자를 불러서 20페이지 분량의 보안 질문서를 내밀고 ‘모두 기입하라’고 요구하기는 어렵다. 그러나 회사 전체에서 사용한다면 그러한 프로세스를 정할 수 있다”고 말했다.

더 투명하게 처리하는 로우코드 업체도 있다. 로우코드 개발 플랫폼 아웃시스템즈(OutSystems)의 제품 마케팅 책임자인 마이크 휴즈는 “우리는 닷넷 코드를 생성한다. 사용자는 소프트웨어로 이 코드의 보안 문제를 검사해서 실행 중인 코드가 안전하다는 것을 확실히 알 수 있다. 많은 고객이 이렇게 한다. 그러나 블랙박스 형태라면 그 안에서 무슨 일이 일어나는지 아무도 알 수 없다”고 말했다.

캡슐8(Capsule8)의 제품 전략 담당 부사장인 켈리 쇼트리지는 이러한 투명성이 없는 로우코드 및 노코드 개발 플랫폼으로 전환하는 경우 보안 팀이 일부 통제력을 상실할 수 있다고 말했다. 그렇다고 항상 보안 문제가 발생한다는 의미는 아니다. 

쇼트리지는 “사용자가 어떤 애플리케이션을 원한다면 직접 코드를 개발하기보다는 표준 플랫폼을 사용해서 만드는 편이 낫다. 구성요소에 취약점이 발견되는 경우 플랫폼 업체가 패치를 만들어 해당 구성요소를 사용하는 모든 애플리케이션을 업데이트할 수 있다”고 말했다.

세일즈포스와 같은 기업은 보관하는 데이터를 안전하게 보호하고 안전한 스크립팅 툴을 만드는 것으로 잘 알려져 있다. 쇼트리지는 “기업에서 자체 코드가 더 안전하다고 생각한다면 착각”이라고 말했다.


4. 데이터를 노출하는 비즈니스 로직 문제

대부분의 로우코드 및 노코드 개발 플랫폼에는 보통 고객을 위해 저장하는 데이터에서 상속되는 권한과 액세스 제어가 기본적으로 포함된다. 이는 숙련된 개발자와 비개발자가 모두 신속하게 안전한 앱을 만드는 데 도움이 된다.

IBM X-포스 레드 사이버 보안 그룹 책임자인 찰스 헨더슨은 “문제는 사람은 여전히 실수를 할 수 있다는 점”이라며 “CISO는 실제 코드가 거의 없거나 아예 없으므로 더 안전할 것이라고 생각하곤 한다. 그러나 플랫폼을 막론하고 보안 측면에서 잘못된 의사 결정이 발생할 가능성을 간과하면 안 된다”고 말했다.

플랫폼 기능이 강화될수록 사람들은 그 플랫폼에서 더 많은 일을 하고 기업의 보안을 더 약화시킬 수 있게 된다. 예를 들어 어느 사용자에게 속한 데이터를 다른 사용자가 보도록 허용하거나 공개된 위치에 민감한 정보를 게시하도록 허용하는 로직 문제는 기업에 큰 문제를 일으킬 수 있다.

헨더슨은 로우코드와 노코드 앱에도 전통적인 방법으로 개발한 소프트웨어에 적용하는 것과 동일한 수준의 보안 테스트를 적용할 것을 권한다. 헨더슨은 “보안 테스트 프로그램은 광범위한 영역을 다룬다. 대기업은 대부분 철저한 보안 테스트 프로그램을 두고 있으며 많은 경우 외부 업체를 사용해 테스트한다. 그러나 로우코드 앱은 다른 애플리케이션이 거치는 수준의 보안 테스트를 받지 않는 경우가 많다”고 말했다.

핸더슨은 “보안 책임자는 내부 개발자를 상대로 교육했던 내용을 가져와 로우코드 플랫폼을 사용할 수도 있는 최종 사용자도 교육해야 한다. 무지함을 막아주는 필터는 없다”고 덧붙였다. editor@itworld.co.kr 


2019.06.26

로우코드와 노코드 개발에서 신경써야 할 4가지 보안 문제

Maria Korolov | CSO
로우코드(low-code)와 노코드(no-code) 개발의 장점은 새로운 애플리케이션의 배포 속도를 빠르게 하고 기술 지식이 없는 사용자도 애플리케이션을 만들 수 있게 해준다는 점이다. 개념 자체는 오래 전부터 존재했다. 그러나 지금의 모바일 및 웹 앱을 만들기 위한 새로운 클라우드 기반 플랫폼과 마이크로소프트 오피스 365, 구글 G 스위트, 세일즈포스와 같은 플랫폼에 내장된 툴 덕분에 앱 개발 역량을 갖춘 사용자 기반이 계속 확대되고 있다.
 
ⓒ Getty Images Bank 

마켓 앤 마켓(Markets and Markets)에 따르면, 로우코드 개발 플랫폼 시장은 2017년 43억 달러 규모에서 2022년 270억 달러 규모로 성장할 전망이다. 포레스터가 글로벌 IT 및 비즈니스 의사 결정자를 대상으로 실시한 최근 설문에 따르면, 실제로 기업의 84%는 로우코드 개발 플랫폼 또는 툴을 도입했으며, 100% 투자 대비 긍정적인 효과를 거뒀다.

클라우드 업체는 기업에 모든 직원의 데이터 관련 작업을 한눈에 볼 수 있는 시야를 제공하면서 글로벌 액세스 제어와 권한을 구현할 수 있다. 따라서 이런 개발 플랫폼은 많은 면에서 이 플랫폼으로 대체되는 기존 기술에 비해 더 안전하다. 그러나 포레스터 설문 응답자의 59%는 로우코드 플랫폼 도입에서 가장 큰 과제로 보안을 꼽았다.

전문가들이 선정한, 기업에서 고려해야 하는 로우코드 앱과 관련된 4가지 보안 우려 사항은 다음과 같다.


1. 가시성 부족

로우코드와 노코드 개발의 가장 큰 과제 가운데 하나는 기업에서 직원들이 무엇을 만들고 있는지 일일이 파악하기가 어려울 수 있다는 점이다. 주니퍼 네트웍스의 위협 연구 책임자는 모니르 하하드는 섀도우 IT 문제와도 관련된다면서 “대부분의 섀도우 IT는 섀도우 개발과 연계된다. 직원이 회사 IT를 우회해 스토리지든, 컴퓨팅이든, 퍼블릭 클라우드 인프라를 설정해 사용할 때 해당 애플리케이션은 클라우드에서 데이터를 처리하도록 허용하는 경우가 많다”고 지적했다.

온프레미스 로우코드 플랫폼 역시 마찬가지의 가시성 문제를 유발할 수 있다. 예를 들어 마이크로소프트 엑셀 스크립트, 매크로는 기업에서 흔히 사용되지만 거의 통제할 수 없다. 가트너 분석가 제이슨 웡은 “데스크톱에 빠른 애플리케이션 개발 툴을 설치하고 앱을 구축하면 IT 부서는 이를 전혀 볼 수 없다”고 말했다.

웡은 클라우드로의 전환이 시야 개선에 도움이 된다면서 “액세스에 거버넌스를 적용할 수 있는 역량이 더 강화되고 역할 기반 권한을 할당할 수 있다”고 말했다. 덕분에 클라우드 기반 플랫폼은 기존 플랫폼에 비해 더 안전하다.

웡은 세일즈포스 앱 빌더 사용이 허가되지 않은 비즈니스 사용자의 경우를 예로 들면서 “이들은 데이터를 추출해서 엑셀에 입력한다. 이 방식은 세일즈포스에서 앱을 구축하는 것보다 덜 안전하다. 세일즈포스의 경우 시야를 확보하고 어떤 일이 일어나는지 파악할 기회가 있는 반면 여기저기 확산되고 공유되는 액세스 데이터베이스는 그렇지 않다”고 말했다.


2 데이터 감독의 부재

기업이 로우코드와 노코드 플랫폼으로 전환할 때 가장 먼저 확인해야 할 점은 데이터가 안전한지 여부다. 플랫폼에 따라 기업은 공유되는 데이터의 종류 또는 사용되는 방식을 제한할 수 있다. 웡은 “샌드박스를 설정해 사용자가 원하는 것을 자유롭게 만들되 미션 크리티컬 데이터에는 액세스하지 못하도록 할 수 있다. 샌드박스 이외의 부분에 액세스해야 하는 경우 예를 들어 사업부와 IT 부서에 ‘나는 HR 소속이지만 앱에 이 고객 데이터가 꼭 필요하다’고 요청할 수 있다. 그러면 해당 데이터에 대한 읽기 전용 액세스 권한을 승인하는 등의 대처가 가능하다”고 설명했다.

최상위의 엔터프라이즈급 플랫폼 중 상당수는 사업부에 다양한 통제 기회를 제공한다. 웡은 “모든 사람에게 모든 것을 개방하면 안 된다는 것만 이해하면 된다”고 말했다.

케나 시큐리티(Kenna Security)의 수석 보안 엔지니어인 제리 갬블린은 기반 데이터의 보안이 코드보다 더 중요한 우려 사항이라면서 “파이 값을 계산하는 소프트웨어라면 회사에 큰 문제가 되지 않는다. 그러나 이 소프트웨어에 민감한 고객 데이터를 입력한다면 문제가 된다. 즉, 데이터를 먼저 생각해야 한다”고 말했다. 

스렛 스택(Threat Stack)의 엔지니어링 담당 부사장 사빈 토마스는 일부 로우코드 및 노코드 플랫폼의 문제점 중 하나는 종종 최종 사용자가 구성과 권한, 액세스 제어에 관한 의사 결정을 내리는 위치에 있다는 점이라고 말했다. 이런 플랫폼에는 고객 데이터가 격리되고 분할되는 방식에 근본적인 위험이 있다. 토마스는 “효과적인 데이터 분리를 위해서는 액세스 및 역할 정의를 구현해야 하는데, 이 작업은 일반적으로 정작 로우코드 플랫폼의 주된 사용자인 일반 직원 개발자는 할 수 없는 일”이라고 말했다.

토마스는 로우코드 플랫폼마다 세분화된 제어 기능이 다르다고 덧붙였다. 예를 들어 구글 문서 및 기타 협업 플랫폼에는 일반적으로 데이터의 열람과 편집, 공유를 제어하는 액세스 메커니즘이 있다. 토마스는 “그러나 로그인 및 재공유, 시한부 액세스의 자동 만료 및 더 세부적인 액세스 제어가 가능한 고급 통제 역량은 기본적인 기능 범위를 벗어난다”고 말했다.

디지털 자문 서비스 업체인 스파크하운드(Sparkhound)의 비즈니스 자동화 담당 이사인 리처드 살리나스는 일부 로우코드 플랫폼의 경우 사용자가 여러 시스템 및 데이터 소스에 연결되는 애플리케이션을 만들도록 허용한다는 점 역시 문제라고 지적했다. 살리나스는 “모든 데이터 소스에는 자체적인 보안 메커니즘이 있다. 예를 들어 앱이 셰어포인트 사이트에 연결될 때 적용되는 거버넌스와 권한이 적합하지 않는 경우가 있다”고 말했다.

이 경우 엉뚱하게 개발 플랫폼이 보안 문제의 원인으로 지목될 수 있지만 살리나스는 “개발 플랫폼이 아닌 데이터 소스와 데이터 소스 관리자의 문제”라고 말했다.


3. 업체 시스템에 대한 감사의 부재

로우코드 또는 노코드 플랫폼 업체가 구현하는 코드 및 보안 통제 수단은 기업에서 볼 수 없는 경우가 많다. 이런 업체가 얼마나 안전한지 확인하려면 이미 사용 중인 서드파티 보안 감사, 보안 및 규정 준수 인증, 서비스 수준 협약, 사이버 보안 보험과 같은 툴에 의존해야 한다.

한 명의 최종 사용자가 특정 플랫폼을 사용하기로 결정하는 것과 기업이 전사적으로 이 플랫폼을 도입하기로 결정하는 것은 다르다. 갬블린은 “개별 사용자가 SaaS 서비스를 이용할 경우 그 사용자를 불러서 20페이지 분량의 보안 질문서를 내밀고 ‘모두 기입하라’고 요구하기는 어렵다. 그러나 회사 전체에서 사용한다면 그러한 프로세스를 정할 수 있다”고 말했다.

더 투명하게 처리하는 로우코드 업체도 있다. 로우코드 개발 플랫폼 아웃시스템즈(OutSystems)의 제품 마케팅 책임자인 마이크 휴즈는 “우리는 닷넷 코드를 생성한다. 사용자는 소프트웨어로 이 코드의 보안 문제를 검사해서 실행 중인 코드가 안전하다는 것을 확실히 알 수 있다. 많은 고객이 이렇게 한다. 그러나 블랙박스 형태라면 그 안에서 무슨 일이 일어나는지 아무도 알 수 없다”고 말했다.

캡슐8(Capsule8)의 제품 전략 담당 부사장인 켈리 쇼트리지는 이러한 투명성이 없는 로우코드 및 노코드 개발 플랫폼으로 전환하는 경우 보안 팀이 일부 통제력을 상실할 수 있다고 말했다. 그렇다고 항상 보안 문제가 발생한다는 의미는 아니다. 

쇼트리지는 “사용자가 어떤 애플리케이션을 원한다면 직접 코드를 개발하기보다는 표준 플랫폼을 사용해서 만드는 편이 낫다. 구성요소에 취약점이 발견되는 경우 플랫폼 업체가 패치를 만들어 해당 구성요소를 사용하는 모든 애플리케이션을 업데이트할 수 있다”고 말했다.

세일즈포스와 같은 기업은 보관하는 데이터를 안전하게 보호하고 안전한 스크립팅 툴을 만드는 것으로 잘 알려져 있다. 쇼트리지는 “기업에서 자체 코드가 더 안전하다고 생각한다면 착각”이라고 말했다.


4. 데이터를 노출하는 비즈니스 로직 문제

대부분의 로우코드 및 노코드 개발 플랫폼에는 보통 고객을 위해 저장하는 데이터에서 상속되는 권한과 액세스 제어가 기본적으로 포함된다. 이는 숙련된 개발자와 비개발자가 모두 신속하게 안전한 앱을 만드는 데 도움이 된다.

IBM X-포스 레드 사이버 보안 그룹 책임자인 찰스 헨더슨은 “문제는 사람은 여전히 실수를 할 수 있다는 점”이라며 “CISO는 실제 코드가 거의 없거나 아예 없으므로 더 안전할 것이라고 생각하곤 한다. 그러나 플랫폼을 막론하고 보안 측면에서 잘못된 의사 결정이 발생할 가능성을 간과하면 안 된다”고 말했다.

플랫폼 기능이 강화될수록 사람들은 그 플랫폼에서 더 많은 일을 하고 기업의 보안을 더 약화시킬 수 있게 된다. 예를 들어 어느 사용자에게 속한 데이터를 다른 사용자가 보도록 허용하거나 공개된 위치에 민감한 정보를 게시하도록 허용하는 로직 문제는 기업에 큰 문제를 일으킬 수 있다.

헨더슨은 로우코드와 노코드 앱에도 전통적인 방법으로 개발한 소프트웨어에 적용하는 것과 동일한 수준의 보안 테스트를 적용할 것을 권한다. 헨더슨은 “보안 테스트 프로그램은 광범위한 영역을 다룬다. 대기업은 대부분 철저한 보안 테스트 프로그램을 두고 있으며 많은 경우 외부 업체를 사용해 테스트한다. 그러나 로우코드 앱은 다른 애플리케이션이 거치는 수준의 보안 테스트를 받지 않는 경우가 많다”고 말했다.

핸더슨은 “보안 책임자는 내부 개발자를 상대로 교육했던 내용을 가져와 로우코드 플랫폼을 사용할 수도 있는 최종 사용자도 교육해야 한다. 무지함을 막아주는 필터는 없다”고 덧붙였다. editor@itworld.co.kr 


X