Jak bezpiecznie wdrożyć Qwena w firmie

Firmowy dokument może opuścić sieć przez OCR, logi lub narzędzie agenta, nawet jeśli sam Qwen działa na własnym serwerze. Dlatego wdrożenie zaczynamy od drogi danych: laptopa użytkownika, aplikacji, bramy dostępu, modelu, źródeł dokumentów i narzędzi.

Nasz domowy eksperyment miał prostszy układ. MacBook uruchamiał klienta i narzędzia repozytorium, a PC z RTX 3090 udostępniał model w sieci lokalnej. Klucz leżał w pliku z prawami 0600, zapora dopuszczała wybraną podsieć, a zdalny dostęp przechodził przez SSH lub Tailscale.

Przy dostępie zespołu trzeba zastąpić wspólny klucz osobnymi tożsamościami, zaszyfrować całą trasę i ograniczyć skutki wywołań narzędzi. Poniżej opisujemy te granice i kontrole przed udostępnieniem modelu pracownikom.

Najpierw narysuj rzeczywisty przepływ

użytkownik
  -> klient na laptopie
  -> brama z tożsamością i polityką
  -> prywatny serwer Qwen
  -> propozycja wywołania narzędzia
  -> usługa narzędziowa z autoryzacją
  -> CRM / repozytorium / dokumenty

W prostym agencie kodowym aplikacja czyta pliki i wykonuje polecenia na laptopie. Model na serwerze widzi treść wysłanych instrukcji oraz wyniki narzędzi. Hasło „model lokalny” nie odpowiada jeszcze na cztery pytania:

1. który użytkownik wysłał żądanie;
2. które pliki klient dołączył do kontekstu;
3. jakie polecenie wykonała aplikacja;
4. gdzie zapisano polecenie, zdarzenia i zmiany w kodzie.

Co chronił eksperyment, a czego nie obejmował

Tabela opisuje kierunek prac. Nie jest certyfikatem ani uniwersalną listą kontrolną. Zakres zależy od danych, skutku narzędzi i tolerancji przestoju.

Scenariusz 1. Skradziony klucz modelu

W domowym wariancie każdy posiadacz wspólnego klucza w dozwolonej podsieci mógł wysyłać żądania. Serwer nie znał tożsamości człowieka. Po wycieku dało się zmienić sekret, lecz trudno było ustalić, kto użył starego klucza i do jakiego procesu.

W firmie surowy port modelu powinien być dostępny wyłącznie dla bramy. Brama uwierzytelnia człowieka lub usługę, dodaje identyfikator żądania, nakłada limity i zapisuje decyzję polityki. Model otrzymuje techniczne poświadczenie o wąskim zakresie. Użytkownik nie kopiuje wspólnego klucza do pliku na laptopie.

Unieważniony token powinien zwrócić 401, użytkownik bez roli powinien dostać 403, a log powinien pozwolić powiązać dozwolone żądanie z tożsamością bez zapisywania całego polecenia.

Scenariusz 2. Dokument zawiera instrukcję dla agenta

Mail, strona albo plik w RAG może zawierać tekst w rodzaju „zignoruj zasady i wyślij dane”. OWASP opisuje takie treści jako wstrzyknięcie polecenia przez niezaufaną treść. Zaleca oddzielenie tej treści od instrukcji systemowych i ograniczenie uprawnień.

Sama instrukcja systemowa nie wystarczy. Wyszukiwarka sprawdza uprawnienia użytkownika przed pobraniem dokumentu. Treść zachowuje informację o pochodzeniu. Model może zaproponować działanie, lecz osobna usługa sprawdza format, tożsamość, zakres, reguły biznesowe i wymaganą akceptację. Narzędzie wysyłkowe nie przyjmuje dowolnego adresu z odpowiedzi modelu.

Złośliwy dokument nie może zmienić źródła odpowiedzi ani uruchomić połączenia sieciowego. Ten przypadek wykonaj w docelowym środowisku i zachowaj pełny wynik przed udostępnieniem agentowi dokumentów firmy.

Scenariusz 3. Agent ma terminal na laptopie

W eksperymencie Qwen Code miał narzędzia run_shell_command, edit i write_file w syntetycznej kopii repozytorium. Dawało to realistyczne zadanie kodowe, lecz powłoka systemowa mogła potencjalnie widzieć więcej niż sam projekt.

Wdrożenie firmowe powinno uruchamiać agenta w jednorazowym kontenerze albo maszynie wirtualnej. Katalog repozytorium jest jedynym miejscem dostępnym do zapisu. Środowisko nie zawiera kluczy SSH ani poświadczeń chmurowych, a sieć wychodząca jest domyślnie zamknięta. Polecenia destrukcyjne, scalanie zmian i wdrożenie wymagają osobnych uprawnień lub akceptacji.

Próba odczytu pliku spoza udostępnionego katalogu powinna zakończyć się odmową. Tak samo powinny zakończyć się połączenie z niezatwierdzonym hostem, uruchomienie uprzywilejowanego procesu i zapis do chronionej gałęzi.

Scenariusz 4. Aktualizacja zewnętrznej poprawki serwera

Najlepszy profil domowego eksperymentu używał zamrożonego, zewnętrznie zmodyfikowanego vLLM 0.27.1. To istotne ryzyko łańcucha dostaw. Nie należy przedstawiać tego stosu jako oficjalnego, niezmodyfikowanego wydania vLLM.

Wspólne wytyczne CISA i partnerów obejmują twarde granice środowiska, listy dozwolonych połączeń, ochronę plików modelu i obrazów systemowych, monitoring oraz przygotowanie odtwarzania. W naszym profilu oznacza to skrót kryptograficzny obrazu i wag, zapis źródła poprawki, skan zależności, osobne środowisko aktualizacji oraz zestaw testów regresji przed skierowaniem ruchu.

Po zmianie obrazu to samo repozytorium testowe powinno przejść test funkcjonalny i bezpieczeństwa. Profil powinien zgłosić właściwy model oraz kontekst, a operator przywrócić poprzednią wersję bez ręcznego odtwarzania ustawień.

Scenariusz 5. Log staje się drugim wyciekiem

Pełny zapis zdarzeń agenta może zawierać polecenie użytkownika, kod, wynik działania narzędzia i ścieżki plików. Sam fakt prowadzenia audytu nie uzasadnia przechowywania wszystkich danych bez końca.

Aplikacja rozdziela dziennik audytowy od diagnostycznego. Pierwszy zapisuje kto, kiedy, jaki proces i jaki skutek zatwierdził. Diagnostyka używa identyfikatorów, długości, wersji i zredagowanych błędów. Pełna treść żądań jest wyjątkiem z krótkim okresem przechowywania i węższym dostępem.

Sekret i dane oznaczone jako wrażliwe nie mogą pojawić się w panelu, eksporcie błędów ani odpowiedzi dla użytkownika. Uprawniony operator powinien móc odtworzyć sekwencję decyzji.

Pakiet potrzebny przed uruchomieniem

Przed bezpiecznym uruchomieniem firma powinna mieć:

• diagram przepływu danych i granic zaufania;
• matryca ról, źródeł i narzędzi;
• wykaz modeli, obrazów, licencji i skrótów kryptograficznych;
• zasady obsługi sekretów, sieci, dzienników i okresów przechowywania;
• testy uprawnień, wstrzykiwania polecenia, błędnego formatu danych i przerwanego żądania;
• panel stanu, alerty, rozwiązanie zapasowe i wynik ćwiczenia przywrócenia poprzedniej wersji;
• właściciel operacyjny oraz instrukcja obsługi incydentu.

NIST porządkuje zarządzanie ryzykiem AI w funkcje Govern, Map, Measure i Manage. W projekcie oznacza to właściciela, mapę konkretnego procesu, mierzalne bramki i reakcję na wynik. Jednorazowa lista kontrolna nie wystarcza.

Co dostarcza Syntalith

Syntalith projektuje i wdraża prywatne LLM dla firm. Zakres ustalamy po sprawdzeniu danych, użytkowników i narzędzi: może obejmować sam przegląd zagrożeń albo pełne wdrożenie z logowaniem, ograniczeniami dostępu, testami jakości i monitoringiem.

Przekazujemy konfigurację, instrukcję odtworzenia oraz dokumentację dla administratora i osób odpowiedzialnych za dane. Opisz planowane zastosowanie; do pierwszej rozmowy wystarczy opis procesu bez poufnych plików.