OWASP 공식 권고, ‘계정사칭, 권한 오용, 데이터 누출, 통신실패’ 등
각 보안 취약점 대비 ‘예방책’도 제시, “LC/NC 대중화 시대의 필수 보안수칙”
[애플경제 김예지 기자] 로우코드(LC) 내지 노코드(NC)에 의한 프로그래밍이 날로 대중화되면서, 이로 인한 보안의 문제점도 부각되고 있다. 최근 개방형 커뮤니티인 OWASP(The Open Worldwide Application Security Project)는 LC/NC 작업으로 인한 계정 사칭, 권한 오용 등 대표적인 10가지 보안 위험을 소개하고 있어 눈길을 끈다.
OWASP는 “Low-Code/No-Code 개발 플랫폼은 기존의 수작업 코딩 양을 줄여 비즈니스 애플리케이션의 보급을 가속화한다”면서 “그러나 이러한 플랫폼에서 개발된 애플리케이션과 관련된 보안 및 개인 정보 보호 위험에 대한 명확한 인식이 필요하다”고 강조했다.
이를 위해 이른바 “‘OWASP Low-Code/No-Code Top 10’을 통해 그 중에서도 가장 대표적인 보안 위험과, 문제점, 이를 극복하는 방법에 대한 정보를 제공한다”고 밝혔다.
이를 다시 번역, 요약한 우리은행 홍동희 차장은 ▲계정 사칭과 ▲권한 오용을 비롯해 ▲데이터 누출 및 예상하지 못한 결과 ▲ 인증 및 안전한 통신 실패 ▲보안 구성 오류 ▲인젝션 처리 실패 ▲취약하고 신뢰할 수 없는 구성 요소 ▲데이터 및 비밀 처리 실패 ▲자산 관리 실패 ▲보안 로깅 및 모니터링 실패 등 ‘Top 10’을 정보통신기획평가원 보고서를 통해 소개했다.
이에 따르면 그 중 ▲‘계정 가장’은 사용자 계정에 숨어 실제 사용자를 확인할 수 없는 상태다. LC/NC 애플리케이션은 모든 애플리케이션 사용자가 암묵적으로 개발자 계정에 포함될 수 있다. 이로 인해 공격자가 기존 보안 제어를 우회, 다른 사용자의 신원 뒤에 숨을 수 있다는 얘기다.
이를 예방하기 위해선 데이터베이스, 서비스 등에 연결할 때는 최소권한 원칙을 준수하도록 해야 한다는 주문이다. 또 “애플리케이션이 모든 연결 과정에서 일관된 단일 ID를 사용하고, 애플리케이션을 통해 연결하거나, 접근권한을 부여한 경우, 공유된 연결을 통해 수행된 작업내역을 식별할 수 있도록 기록을 유지해야 한다”는 것이다.
다음은 ▲‘권한 오용’의 위험이다. LC/NC 플랫폼에서 애플리케이션, 다른 사용자, 전체 조직 간에도 연결이 이뤄진다. 애플리케이션이 삭제되더라도 데이터 등에 계속 접근할 수 있다. 그 결과 애플리케이션 접근권한이 없는 사용자와도 애플리케이션이 공유되어 권한이 없는 사용자에게 노출될 수 있다.
이를 예방하기 위해선 암묵적으로 공유된 연결의 사용을 비활성화하거나, LC/NC 플랫폼에서 과도하게 공유된 연결을 관리자 등이 모니터링하도록 할 필요가 있다. 접근 권한을 부여할 때 최소권한 원칙을 준수하고, OAuth 토큰을 정기적으로 재인증하는 것도 필요하다.
▲‘데이터 누출과 예상하지 못한 결과’도 위험 요인이다. 즉, 데이터가 조직의 통제를 벗어나 밖으로 이동, 의도하지 않은 결과를 가져오는 것이다. 애초 LC/NC 프로그래밍은 기본 서비스의 데이터에 정당한 절차를 통해 접근하지만, 승인되지 않은 작업 등을 위해 백엔드 시스템에 대한 통로 역할을 할 수도 있다.
이런 데이터 누출을 예방하기 위해서는 다른 시스템 등과 연결된 커넥터를 승인된 서비스 목록으로 제한하고 커넥터 생성을 전담인력으로 제한하는게 필요하다는 주문이다. 또 LC/NC 플랫폼을 모니터링, 경유지를 포함한 조직 경계를 벗어난 데이터 흐름을 확인해야 한다.
네 번째로 ▲‘인증 및 안전한 통신 실패’도 위험요인이다. 통신을 통해 데이터를 주고받는 경우, 중요 데이터에 대한 보안 조치가 미흡할 수 있다. 내장 커넥터를 통한 연결은 기업의 보안정책을 반영하지 않고 암호화 대상 데이터에 전송 구간 암호화를 누락하여 데이터 보호가 취약해질 수 있다. 이를 예방하기 위해선 전담인력으로 연결 생성을 제한하고, 정책을 준수하지 않는 연결에 대한 플랫폼 모니터링을 실시한다.
다섯 번째로 OWASP는 ▲‘보안 구성 오류’를 위험 요인으로 짚었다. 즉, 잘못된 보안 구성으로 인해 중요한 데이터나 작업에 대한 익명 액세스, 보호되지 않는 공용 엔드포인트 및 비밀사항, 과도한 공유 허용과 같은 보안 위험이 발생할 수 있다는 얘기다. 개발된 애플리케이션의 보안 구성을 잘못 반영해, 취약한 비밀번호 생성규칙을 적용하거나, 서버에 파일 업로드 시 악성코드 등 보안 위험의 검사를 생략할 수 있는 위험이 있다.
이를 예방하기 위해선 LC/NC 플랫폼 공급업체의 모범 사례 가이드를 준수하고, 구성이 업계 모범 사례에 부합하는지 확인할 필요가 있다. 또한 드리프트에 대한 구성 모니터링, 테넌트 수준 구성을 위한 변경 관리 시스템 구현도 필요하다.
다음으로 ▲‘인젝션 처리 실패’도 위험 요소다. 인젝션은 공격자가 인터프리터로 전송되는 명령의 의미를 변경할 수 있는 방식이며, 애플리케이션에 데이터를 전송하려는 시도다. 그런 과정에서 애플리케이션의 정상적인 동작을 방해하거나 데이터를 탈취할 수 있다. 더욱이 이러한 인젝션은 사용자가 시스템에 입력한 데이터를 ‘저장하거나 처리할 데이터’가 아닌 ‘실행할 코드’로 해석될 수 있다.
이를 예방하기 위해선 정제되지 않은 사용자 입력의 위험에 대한 경각심을 높일 필요가 있다. 또 SQL을 통한 데이터베이스 상호 작용의 경우, 사용자 입력값을 SQL 문자열에 포함하지 않고, 별도의 매개변수로 처리한다. 또 쿼리 구조 변경 등을 예방할 수 있도록 저장하고 프로시저나, 특수 문자를 안전하게 처리하기 위한 도구를 사용하도록 한다.
▲‘취약하고 신뢰할 수 없는 구성 요소’도 문제다. LC/NC 프로그래밍은 마켓플레이스, 웹 또는 개발자가 구축한 사용자 정의 커넥터에서 미리 만들어진 구성 요소에 크게 의존한다. 이러한 구성 요소는 관리되지 않고 가시성이 부족하며 조직을 공급망 기반 위험에 노출시키는 경우가 많다. 즉 이런 구성 요소는 악의적인 의도로 생성될 뿐만 아니라 다양한 위험을 수반할 수 있다.
이를 예방하기 위해 해당 애플리케이션에서 사용하는 애플리케이션 및 구성 요소 버전을 지속적으로 목록화할 필요가 있다. 더 이상 사용되지 않거나, 취약한 구성 요소가 있는지 해당 인벤토리를 확인하며, 사용 가능한 구성요소를 사전 승인된 마켓플레이스 구성요소로 사용하도록 제한한다.
▲‘데이터 및 비밀 처리 실패’ 또한 LC/NC 프로그래밍의 보안을 해치는 요소다. LC/NC 플랫폼에선 데이터나 비밀을 ‘코드’의 일부로 저장하거나, 플랫폼에서 제공하는 관리형 데이터베이스에 저장하는 경우가 많다. 개발자는 어떤 데이터가 민감한 데이터”로 간주되는지, 또는 암호화 등 해당 데이터를 보호하는 프로세스를 알지 못한다. 이로 인해 민감한 정보가 노출될 수 있다.
이를 예방하기 위해선 데이터 저장과 관련된 규정 준수, 개인정보 보호 및 보안 위험에 대한 교육이 필요하다. 또 민감한 데이터에 대해 LC/ NC 플랫폼 제공업체에서 제공하는 관리형 데이터베이스, 환경 변수 및 구성을 모니터링해야 한다.
▲‘자산 관리 실패’도 위험요인이다. LC/NC 플랫폼에 의해 낮은 유지 비용으로 누구나 쉽게 애플리케이션을 만들다보니, 어떤 애플리케이션이 존재하는지, 어떻게 유지 관리하는지, 누가 ‘소유’하는지 추적하는 것이 어렵다. 이렇게 식별되지 않은 자산에서 처리되는 자동화된 프로세스 역시 그 거래이력과 변경 등을 관리할 수가 없다. 이에 “애플리케이션, 구성 요소 나 사용자를 나열하는 포괄적인 목록을 관리하고, 사용되지 않는 종속성, 불필요한 기능, 구성 요소, 파일 및 문서를 확인, 제거하거나 비활성화하도록 해야한다”는 주문이다.
끝으로 ▲‘보안 로깅 및 모니터링 실패’가 있다. LC/NC 애플리케이션은 공급업체에 의존, 로그를 생성하고 데이터를 모니터링하는 경우가 많다. 그렇다보니 포괄적인 감사 추적이 부족하고, 항목이 일부 누락되는 등 불충분하거나 존재하지 않는 로그가 생성되거나, 민감한 로그에 대한 액세스가 과도하게 허용되는 경우가 있다. 누가 앱에 액세스했는지, 무엇을 하려고 했는지도 확인할 수 없다.
“이를 예방하기 위해선 플랫폼 내장 기능을 활용, 사용자 액세스 및 플랫폼 감사 로그를 수집해야 한다. 또한 로그가 민감한 데이터를 포함하거나, 노출되지 않도록 해야 한다”는 조언이다.