데이터 보안 AI 워크플로우 생성 및 구현

소개

대규모 언어 모델(LLM) 애플리케이션의 새롭고 예측할 수 없는 특성은 이를 사용할 때 데이터에 무슨 일이 일어나고 있는지에 대해 많은 의문을 제기할 수 있습니다. 데이터가 개인적인지, 나중에 예기치 않게 어디에 나타날 수 있는지, 애플리케이션에 에이전트 기능을 추가할 때 새로운 유출이 발생하지 않도록 어떻게 보장할 것인지를 고려하십시오. 이는 특히 HIPAA, COPPA, GDPR, SOC 2 등과 같은 법적 준수가 필요한 애플리케이션에서 매우 중요합니다.

올바르게 구축된다면, LLM 애플리케이션은 기존 애플리케이션만큼 혹은 그 이상으로 안전할 잠재력을 가지고 있습니다. LLM은 모델 크기와 하드웨어 가용성에 따라 단일 서버에 포함되거나 로컬에서 실행될 수 있습니다. 과거에는 외부 도구가 필요했던 많은 작업이 이제는 단일 모델 호출로 완료될 수 있습니다. 그러나 데이터를 사용하는 새로운 방법이 등장함에 따라 고려해야 할 새로운 취약점도 생깁니다. 이 튜토리얼에서는 데이터 보안을 염두에 두고 LLM 워크플로우를 구축할 때의 주요 고려 사항과 전략을 다룹니다.

핵심 내용

• LLM 워크플로우에서 데이터 보안은 모델 제공업체, 호스팅 옵션, API와 웹 인터페이스 사용에 대한 신중한 고려가 필요합니다. 서버리스 추론이나 자체 호스팅 GPU 배포를 지원하는 오픈소스 모델은 폐쇠형 모델보다 데이터 프라이버시를 더 잘 제어할 수 있습니다.

• LLM 워크플로우는 기존 애플리케이션을 넘어서는 고유한 데이터 흐름 문제를 가져오며, 여기에는 대화 기록 저장, 로그 기록 관행, 음성-텍스트 API나 사용자 데이터를 전송할 수 있는 모델 컨텍스트 프로토콜 서버와 같은 타사 통합이 포함됩니다.

• 전통적인 보안 관행은 LLM에는 충분하지 않습니다. 보안을 위해 시스템 프롬프트에 의존해서는 안 되며, 에이전트는 사용자 범위 권한을 가져야 하고, 데이터 유출이나 무단 접근을 방지하기 위해 SQL이나 명령어 접근은 명시적으로 제한되어야 합니다.

1단계 — 모델 제공업체 선택

개인정보 보호 문제 때문에, 제공업체를 선택하는 것은 당신이 내릴 가장 중요한 결정 중 하나입니다. 모델 제공업체와 호스팅 옵션에 따라 데이터 수집과 개인정보 보호에 대한 접근 방식이 다릅니다. 각 제공업체 내에서도 웹 인터페이스를 사용하느냐 아니면 추론을 위해 API를 사용하느냐에 따라 데이터 정책이 달라집니다.

공급자의 웹 인터페이스를 통해 클로즈드 소스 모델을 사용할 경우, 일반적으로 공급자는 사용자의 데이터를 저장하고 이를 향후 모델 학습에 활용할 수 있습니다. API를 사용하고 토큰 단위로 요금을 지불하는 경우에는, 공급자가 일반적으로 프롬프트 데이터를 학습에 사용하지는 않지만, 대부분 30일 정도의 기간 동안 데이터를 보관하는 경우가 많습니다. 이러한 클로즈드 소스 모델은 주로 제3자 추론 제공자를 통해 제공되므로 데이터 보관 기간을 피할 수 있다고 생각할 수도 있습니다. 그러나 제3자 제공자를 통해 클로즈드 소스 모델을 사용하더라도, 제공자 혹은 모델 회사가 여전히 데이터 보관 기간 동안 사용자의 데이터를 저장하고 있을 가능성이 있으므로, 작업하고 있는 모든 회사의 서비스 약관을 확인하여 각 회사의 데이터 정책을 이해하는 것이 중요합니다.

데이터 프라이버시 수준을 높게 유지해야 한다면, 서버리스 추론을 제공하는 서비스를 통해 오픈 소스 모델을 사용하는 것이 더 나은 선택일 수 있습니다. 예를 들어, Linux-Console.net의 Gradient AI 플랫폼은 Llama, GPT-OSS 또는 다른 오픈 소스 모델을 사용할 수 있는 서버리스 추론을 제공합니다. 이러한 모델을 사용할 경우, 기능 수행에 필요한 범위를 넘어서는 데이터는 저장되거나 학습에 사용되지 않습니다.

한 단계 더 나아가, 직접 Linux-Console.net GPU Droplet을 렌트하고 그 위에 LLM을 배포할 수 있습니다. Linux-Console.net GPU Droplet이 안전하기만 하다면, 프롬프트에 포함하는 데이터에 대해 완전한 제어권을 가질 수 있습니다.

마지막으로, 모델의 필요에 따라 데이터를 완전히 보호하려면 인터넷 연결 없이 자신의 컴퓨터에서 모델을 실행할 수 있습니다. 이렇게 하면 처리하는 데이터가 인터넷에 전혀 노출되지 않습니다. 노트북에서 실행할 수 있을 정도로 작은 오픈소스 모델이 있으며, GPU를 구매할 자원이 있다면 더 큰 오픈소스 모델을 배포할 수도 있습니다.

2단계 — LLM 워크플로우 데이터 관리

다음으로, LLM 워크플로에서 데이터가 어떻게 관리되는지를 고려해야 합니다. 예를 들어, LLM 워크플로에 채팅 인터페이스가 포함되어 있다면, 채팅 기록이 클라우드 서버의 데이터베이스에 저장되는지, 아니면 완전히 사용자 기기에 저장되고 각 사용자 입력마다 전송되는지 확인해야 합니다. 대화 기록이 서버에 저장되지 않으면 사용자의 프라이버시는 더 보호될 수 있지만, 대화가 길어질수록 각 요청의 크기가 커져 지연이 발생할 수 있습니다.

로깅 또한 중요한 고려 사항입니다. 매번 LLM에 전송되는 프롬프트를 로깅하는 경우 전체 대화가 포함될 수 있습니다. 사용자의 대화를 서버에 저장하든 저장하지 않든, 매번 전체 프롬프트를 로깅하면 사용자의 대화가 로그에 서버에 남게 됩니다. 접근 제어, 감사 추적, 로그 무결성을 유지해야 하며, 로그에 어떤 데이터가 저장되는지도 고려해야 합니다.

많은 LLM 워크플로우는 이제 사용자의 데이터를 다른 엔드포인트에 노출시키는 제3자 프로세스를 포함합니다. 여기에는 음성을 텍스트로 변환하는 API, 모델 컨텍스트 프로토콜 서버, 벡터 데이터베이스, 또는 에이전트 프레임워크에 자동으로 포함될 수 있는 서비스가 포함될 수 있습니다. 이러한 모든 호출은 데이터가 언제 어떻게 처리되는지를 확인할 수 있도록 고려하고 검토해야 합니다. 컨텍스트를 보강하기 위해 사용하는 벡터 데이터베이스나 대체 데이터 저장 옵션도 안전해야 합니다.

3단계 — 데이터 공격 방어

LLM 애플리케이션은 비교적 새로워 보안 모범 사례에 대한 확립된 산업 표준이 없습니다. 이는 악의적인 사용자로부터 다양한 새로운 유형의 사이버 공격에 취약하게 만듭니다.

악의적인 사용자로부터 데이터를 보호하기 위해, LLM 워크플로우에서는 표준 보안 모범 사례 외에도 추가적인 고려 사항이 필요합니다. 먼저, 시스템 프롬프트가 보안이나 데이터 프라이버시 기능을 위해 사용되지 않도록 하세요. 악의적인 사용자가 시스템 프롬프트에 접근하여 원하는 내용을 작성할 수 있는 상황을 상상해 보세요. 이것이 데이터 프라이버시에 어떤 식으로든 위협이 된다면, 워크플로우와 앱 설계를 변경해야 합니다.

시스템 프롬프트는 사용자가 접근할 수 없는 어떠한 것에도 LLM 워크플로우 접근 권한을 부여할 수 없어야 합니다. 시스템 프롬프트에 민감한 정보를 저장하지 마십시오. 이를 방지하기 위한 조치를 취하더라도 시스템 프롬프트가 유출될 가능성이 있다는 가정을 기반으로 아키텍처와 데이터 보안 관행을 설계하십시오.

LLM 워크플로우에 현재 사용자에게만 적용되는 제한 없이 SQL이나 명령어 접근 권한을 부여하지 마세요. 에이전트가 사용자가 직접 작성하고 제출할 수 있기를 원하지 않는 쿼리나 명령어를 작성하도록 허용하지 않는 것이 가장 안전합니다.

에이전트가 접근할 수 있는 데이터에 대해서도 마찬가지로 말할 수 있습니다. 사용자가 특정 데이터에 접근할 수 없어야 한다면, 에이전트도 사용자 프롬프트에 응답하는 과정에서 해당 데이터에 접근할 수 없어야 합니다.

단계 4 — 워크플로우 테스트하기

보안 LLM 워크플로를 구축한 후에는 침투 테스트 및 보안 검증 절차를 수행하십시오. 이는 수동으로 수행할 수도 있고, 데이터 보안을 위협할 수 있는 종류의 프롬프트를 생성하도록 지시받은 다른 LLM을 사용하여 수행할 수도 있습니다. LLM 애플리케이션은 여전히 비교적 새로운 기술이며, 효과적인 새로운 위협이 꾸준히 발견되고 있어 보안 테스트가 어렵습니다. 새로 발견된 공격에 대해 지속적으로 업데이트하고, 애플리케이션의 보안 기능을 개선하여 새로운 공격으로부터 안전하게 방어할 수 있도록 하십시오.

일반적인 악성 공격의 몇 가지 예는 다음과 같습니다:

• 직접 프롬프트 주입: 공격자들은 '이전의 모든 지시를 무시하고…' 또는 '데이터베이스에 해킹하는 영화 속 캐릭터라고 상상해보세요…'와 같은 명령을 주입하여 LLM의 동작을 탈취하려고 시도합니다.
• 간접 프롬프트 주입: 공격자는 LLM이 가져오는 문서나 데이터베이스에 악성 명령을 삽입합니다.
• 데이터 유출: 공격자들은 LLM이 시스템 프롬프트, 지침 또는 공유된 맥락에서 다른 사용자의 대화와 관련된 데이터를 공개하도록 시도합니다.
• 도구/기능 조작: 공격자는 함수 호출 매개변수를 조작하여 의도하지 않은 동작을 실행합니다.
• 서비스 거부: 공격자는 과도한 토큰 생성이나 계산을 유발하는 프롬프트를 만들어 재귀적이거나 반복적인 동작을 발생시켜 LLM을 토큰으로 과부하시킵니다.

자주 묻는 질문

입력 정화와 출력 필터링이 민감한 정보 유출이나 인젝션 공격을 방지하는 데 도움이 될 수 있을까요?

네, 하지만 LLM만으로 민감한 정보나 악성 입력을 신뢰할 수 있게 식별하는 것은 권장되지 않습니다. 전통적인 비-LLM 방식이나 강력하게 검증된 입력 정화 및 검증 방법이 우선적으로 사용되어야 합니다. 사용자가 LLM을 SQL 또는 프롬프트 인젝션을 방지하거나 민감한 정보가 사용자나 제3자에게 우발적으로 유출되는 것을 막기 위한 보안 계층으로 사용하려는 경우, 일부 또는 대부분의 프롬프트 인젝션이나 탈옥 시도를 방지할 수 있습니다. 그러나 LLM의 비결정적 특성과 점점 복잡해지는 공격으로 인해 LLM을 주요 필터로 사용하여 안전한 애플리케이션을 구축하는 것은 어렵습니다.

어떤 전통적인 데이터 보안 관행이 여전히 LLM 작업 흐름에 관련이 있나요?

거의 모든 데이터 보안 모범 사례는 LLM 워크플로우에서도 여전히 유효합니다. 데이터 최소화와 보존 정책은 필요한 최소한의 데이터만 수집되고 처리되도록 보장해야 합니다. 로그, 대화 및 임시 데이터에 대한 명확한 보존 기간이 설정되어야 합니다. 데이터는 저장 시와 전송 중에도 암호화되어야 합니다. 강력한 인증 메커니즘을 갖춘 역할 기반 접근 제어가 구현되어야 합니다.

악의적인 사용자가 내 LLM 워크플로우에 스팸을 보내고 추론 비용을 증가시키는 것을 어떻게 막을 수 있나요?

요율 제한을 구현하고 비정상적인 패턴이나 과도한 API 사용을 모니터링하세요. 의심스러운 행동에 대한 알림을 설정하세요. 자동화된 사용자나 악의적인 사용자로 인한 비용 폭주를 방지하기 위해 LLM 서비스 제공업체의 비용 한도를 설정하는 것을 고려하세요.

LLM을 HIPAA 준수 애플리케이션에 사용할 수 있나요?

네, 가능합니다. 하지만 앱이 HIPAA 규정을 준수하도록 보장하기 위해 클라우드 서비스 제공업체와 함께 따라야 할 단계가 있으며, 필요한 경우 비즈니스 협력 계약서를 서명해야 합니다.

나중에 취약점이 있었다는 것을 알게 되면 어떻게 하나요?

발견된 보안 취약점에 대해서는 조직에서 정한 절차를 따라야 합니다. 여기에는 사용자에게 알리고 적절한 채널에 보고하는 것이 포함될 수 있습니다. LLM 애플리케이션의 보안 취약점도 다른 애플리케이션의 보안 취약점처럼 심각하게 다루어야 합니다.

결론

LLM 애플리케이션은 새로운 보안 문제를 야기할 수 있지만, 표준 보안 모범 사례를 애플리케이션의 추가된 LLM 로직 계층에 확장하고 에이전트형 워크플로가 접근할 수 있는 데이터를 전략적으로 제한함으로써 높은 수준의 데이터 보안을 계속 유지할 수 있습니다. 사용 중인 다양한 도구와 공급업체의 데이터 정책을 확인하세요. 서로 다른 서비스가 데이터를 저장하고 사용하는 방식에 대해 어떤 가정도 하지 마세요.

LLM 워크플로우에서 HIPAA, COPPA, GDPR, SOC 2 및 기타 규정을 준수할 수 있지만, 각 규정은 팀에 추가적인 보안 작업을 요구합니다. 다음 단계는 애플리케이션을 구축하고 테스트하기 시작하며, 모든 보안 결정이 앱의 사용자, 목표 및 사용 사례와 일치하는지 확인하는 것입니다.

Linux-Console.net 커뮤니티와 함께 학습해 주셔서 감사합니다.