LangChain-Get started- Security

목차  LangChain - Get started

1. Introduction
2. Installation
3. Quickstart
4. Security (이번 포스팅 내용)

 

동영상 설명은 아래 링크를 참고해 주세요. 

https://youtu.be/pSjEz7PD_6s

 

 

이전 포스팅까지 잘 따라오셨다면 LangChain에 대해서 이미 많은 것을 이해하고 기본적인 내용을 활용할 수 있게 되었다고 할 수 있겠습니다. 직전 내용인 Quickstart의 내용이 살짝 많은 것 처럼 생각될 수 있는데, 이것은 다양한 형태의 사용을 설명하다 보니 조금 복잡해 진것 같습니다. 하여간 집중해서 보셨다면 이제 LangChain을 이용해서 어느정도 간단한 어플리케이션을 개발/ 구성을 하실 수 있게 됐을 것 같습니다.

이번 시간에는 보안(Security)에 대해서 다루어 보겠습니다.

 

보안(Security)

LangChain은 로컬 및 원격 파일 시스템, API 및 데이터베이스와 같은 다양한 외부 리소스와 통합된 대규모 생태계를 보유하고 있습니다. 이러한 통합은 개발자가 LLM의 강력한 기능을 활용하면서 외부 리소스(서비스)에 액세스하고 상호 작용 할 수 있는 다양한 응용 프로그램을 만들 수 있게 합니다.

예를 들면 아이언맨에 나오는 자비스 같은 것을 말합니다. 자비스는 랭체인을 기반으로 구현할 수 있는 언어 모델 어플리케이션의 좋은 예라고 할 수 있겠습니다. (LLM 이) 사용자(토니)의 말을 잘 알아 듣고 대답을 생성하며, 필요하면 (LangChain 이 하는 것 처럼) 외부의 시스템/서비스에 접속해서 필요한 정보를 가져오거나 필요한 동작을 실행 합니다. 이런 어플리케이션의 특징이 있기 때문에 전통적인 보안의 관점에서 좀더 확장된 시각의 접근이 필요한 것 같습니다. 왜냐하면 하나의 서비스 완성을 위해서 여러 기능의 연결점이 많고, 내부와 외부 서비스로 다양하기 때문입니다. 즉, LLM의 특징과 언제 어떻게 사용될 지 모르는 불확실 성에서 오는 잠재적 위험이라고 할 수 있겠습니다.

 

최적의 방법

이러한 응용 프로그램을 개발할 때 개발자는 다음과 같은 좋은 보안 관행을 따르는 것이 중요합니다.

• 권한 제한: 응용 프로그램이 필요한 권한을 구체적으로 제한하세요. 넓거나 과도한 권한 부여는 중대한 보안 취약점이 될 수 있습니다. 이러한 취약점을 피하려면 읽기 전용 자격 증명을 사용하거나 민감한 리소스에 대한 액세스를 금지하거나 적절한 샌드박싱 기술(컨테이너 내에서 실행)을 사용하는 것을 고려하십시오. 이처럼 권한을 제한하는 것은 어찌보면 당연한 일이지만 어플리케이션의 구성이 더 복잡해 짐에 따라 더 중요한 포인트입니다. 
• 잠재적인 남용 예측: 인간이 실수할 수 있듯이 대형 언어 모델(LLM)도 실수 할 수 있습니다. 어떤 시스템 액세스 또는 자격 증명이든지 간에 할당된 권한이 허용하는 모든 방식으로 사용될 수 있다고 가정하십시오. 예를 들어 데이터베이스 자격 증명이 데이터 삭제를 허용한다면 해당 자격 증명을 사용할 수 있는 모든 LLM이 실제로 데이터를 삭제할 수 있다고 가정하는 것이 가장 안전합니다.
• 깊이 있는 방어: 어떤 보안 기술도 완벽하지 않습니다. Fine-tuning 및 좋은 체인 디자인은 대형 언어 모델(LLM)이 실수를 할 확률을 줄일 수 있지만 완전히 제거할 수는 없습니다. 보안을 보장하기 위해 단일 방어 계층에 의존하는 대신 여러 겹의 보안 접근 방식을 결합하는 것이 가장 좋습니다. 예를 들어 읽기 전용 권한과 샌드박싱을 모두 사용하여 LLM이 명시적으로 사용하도록 허용된 데이터에만 액세스할 수 있도록 보장할 수 있습니다.

보안 관행을 따르지 않으면 다음과 같은 리스크가 발생할 수 있습니다(당연하지만 이보다 더할 수 있습니다.):

• 데이터 손상 또는 손실.
• 기밀 정보에 대한 무단 액세스.
• 핵심 리소스의 성능 또는 가용성에 대한 손상.

예시 시나리오 및 완화 전략:

• 사용자가 파일 시스템에 액세스 권한이 있는 에이전트에게 삭제해서는 안 될 파일을 삭제하거나 민감한 정보가 포함된 파일의 내용을 읽도록 요청할 수 있습니다. 완화를 위해 에이전트를 특정 디렉토리만 사용하도록 제한하고 읽거나 쓸 수 있는 안전한 파일만 허용하도록 합니다. 에이전트를 컨테이너 내에서 실행하여 추가로 샌드박스 처리하는 것도 고려합니다.
• 사용자가 외부 API에 쓰기 권한이 있는 에이전트에게 악의적인 데이터를 API에 기록하거나 해당 API에서 데이터를 삭제할 수 있습니다. 완화를 위해 에이전트에게 읽기 전용 API 키를 부여하거나 이미 그런 남용에 대한 견딜 수 있는 엔드포인트만 사용하도록 제한할 수 있습니다.
• 사용자가 데이터베이스에 액세스할 수 있는 에이전트에게 테이블을 삭제하거나 스키마를 변형할 수 있습니다. 완화를 위해 에이전트가 액세스해야 하는 테이블에 권한을 제한하고 읽기 전용 자격 증명을 발급하는 것을 고려합니다.

만약 여러분이 회사에서 외부 리소스에 액세스하는 응용 프로그램을 개발 중이라면 회사의 보안 팀과 상의하여 응용 프로그램을 최적으로 설계하고 보안을 강화하는 방법을 결정하는 것이 좋습니다.

 

취약점 보고하기

보안 취약점이 있다면 security@langchain.dev 로 이메일을 통해 신고해 주세요. 이렇게 하면 문제가 즉각적으로 처리되고 필요한 대응이 이루어집니다.  

 

기업 솔루션

LangChain은 추가적인 보안 요구사항을 가지고 있는 고객을 위해 기업 솔루션을 제공할 수 있습니다. sales@langchain.dev로 연락주시기 바랍니다.

 

기타

가장 기본적이면서, 중요하면서, 잊기 쉬운 것이 바로 Key 관리 아닌가 싶습니다. 자체 모델과 서비스를 이용해서 통합하고 어플리케이션을 만들면 Key 관리 Risk가 적겠지만, 쉽고, 빠르고, 높은 품질의 어플리케이션을 만들려면 외부 서비스와의 통합이 필수적이게 되고 이때 Key와 Credential을 사용하게됩니다. 그래서 위의 예시 시나리오에서도 나왔지만 API 사용시 적절한 Key 관리가 매우 중요합니다. 코드에 Key를 포함하지 않는 것은 기본이고, 용도와 최소한의 권한을 부여한 Key를 사용하고 주기적으로 점검하고 관리하는 것이 중요합니다. 

 

이것으로 LangChain을 사용할 때 보안 관점에서의 필요성과 보안 모범 사례를 알아보았고,

예상 시나리오에 대한 적절한 완화 전략과 기타 보안 관련 내용에 대해서 이야기해 보았습니다.

 

동영상 설명 : https://youtu.be/pSjEz7PD_6s