Architect Defense-in-depth Security for generative AI-applikasjoner ved å bruke OWASP Topp 10 for LLMs | Amazon Web Services

Generativ kunstig intelligens (AI)-applikasjoner bygget rundt store språkmodeller (LLM) har vist potensialet til å skape og akselerere økonomisk verdi for bedrifter. Eksempler på applikasjoner inkluderer samtalesøk, kundestøtteagenthjelp, kundestøtteanalyse, selvbetjente virtuelle assistenter, chatbots, rik mediegenerasjon, innholdsmoderasjon, koding følgesvenner for å akselerere sikker, høy ytelse programvareutvikling, dypere innsikt fra multimodale innholdskilder, akselerasjon av organisasjonens sikkerhetsundersøkelser og -reduksjoner, og mye mer. Mange kunder leter etter veiledning om hvordan de skal administrere sikkerhet, personvern og overholdelse når de utvikler generative AI-applikasjoner. Å forstå og adressere LLM-sårbarheter, trusler og risikoer under design- og arkitekturfasene hjelper teamene med å fokusere på å maksimere de økonomiske og produktivitetsfordelene generativ AI kan gi. Å være klar over risikoer fremmer åpenhet og tillit til generative AI-applikasjoner, oppmuntrer til økt observerbarhet, bidrar til å møte samsvarskrav og letter informert beslutningstaking av ledere.

Målet med dette innlegget er å gi AI og maskinlæring (ML) ingeniører, dataforskere, løsningsarkitekter, sikkerhetsteam og andre interessenter i stand til å ha en felles mental modell og rammeverk for å anvende beste praksis for sikkerhet, slik at AI/ML-team kan bevege seg raskt uten å bytte ut sikkerhet for hastighet. Spesifikt søker dette innlegget å hjelpe AI/ML og dataforskere som kanskje ikke tidligere har vært utsatt for sikkerhetsprinsipper med å få en forståelse av kjernesikkerhet og beste praksis for personvern i sammenheng med utvikling av generative AI-applikasjoner ved bruk av LLM. Vi diskuterer også vanlige sikkerhetsproblemer som kan undergrave tilliten til AI, som identifisert av Åpne Worldwide Application Security Project (OWASP) Topp 10 for LLM-applikasjoner, og vis måter du kan bruke AWS for å øke sikkerhetsstillingen og selvtilliten din mens du nyter nytt med generativ AI.

Dette innlegget gir tre veilede trinn for å bygge risikostyringsstrategier mens du utvikler generative AI-applikasjoner ved hjelp av LLM-er. Vi går først i dybden med sårbarhetene, truslene og risikoene som oppstår ved implementering, utrulling og bruk av LLM-løsninger, og gir veiledning om hvordan du kan begynne å innovere med sikkerhet i tankene. Vi diskuterer deretter hvordan det å bygge på et sikkert grunnlag er avgjørende for generativ AI. Til slutt kobler vi disse sammen med et eksempel på LLM-arbeidsbelastning for å beskrive en tilnærming til arkitektur med dybdeforsvarssikkerhet på tvers av tillitsgrenser.

Mot slutten av dette innlegget, AI/ML-ingeniører, datavitere og sikkerhetsinteresserte teknologer vil være i stand til å identifisere strategier for å bygge lagdelte forsvar for deres generative AI-applikasjoner, forstå hvordan man kan kartlegge OWASP Topp 10 for LLMs sikkerhetsproblemer til noen tilsvarende kontroller, og bygge grunnleggende kunnskap mot svar på følgende topp AWS-kundespørsmålstemaer for applikasjonene deres:

Hva er noen av de vanlige sikkerhets- og personvernrisikoene ved bruk av generativ AI basert på LLM-er i applikasjonene mine som jeg kan påvirke mest med denne veiledningen?
Hva er noen måter å implementere sikkerhets- og personvernkontroller i utviklingslivssyklusen for generative AI LLM-applikasjoner på AWS?
Hvilke operasjonelle og tekniske beste praksiser kan jeg integrere i hvordan organisasjonen min bygger generative AI LLM-applikasjoner for å håndtere risiko og øke tilliten til generative AI-applikasjoner som bruker LLM-er?

Forbedre sikkerhetsresultatene mens du utvikler generativ AI

Innovasjon med generativ AI ved bruk av LLM-er krever å starte med sikkerhet i tankene for å utvikle organisasjonsmessig robusthet, bygge på et sikkert grunnlag og integrere sikkerhet med en dyptgående sikkerhetstilnærming. Sikkerhet er en felles ansvar mellom AWS- og AWS-kunder. Alle prinsippene i AWS Shared Responsibility Model gjelder for generative AI-løsninger. Oppdater forståelsen din av AWS Shared Responsibility Model slik den gjelder infrastruktur, tjenester og data når du bygger LLM-løsninger.

Start med sikkerhet i tankene for å utvikle organisasjonsmessig robusthet

Start med sikkerhet i tankene for å utvikle organisasjonsmessig robusthet for å utvikle generative AI-applikasjoner som oppfyller dine sikkerhets- og samsvarsmål. Organisatorisk motstandskraft trekker på og utvider definisjon av resiliens i AWS Well-Architected Framework å inkludere og forberede en organisasjons evne til å komme seg etter forstyrrelser. Vurder din sikkerhetsstilling, styring og dyktighet når du vurderer den generelle beredskapen til å utvikle generativ AI med LLM-er og organisasjonens motstandsdyktighet overfor potensielle påvirkninger. Ettersom organisasjonen din fremmer bruken av nye teknologier som generativ AI og LLM, bør generell organisasjonsmessig robusthet betraktes som en hjørnestein i en lagdelt defensiv strategi for å beskytte eiendeler og forretningsområder mot utilsiktede konsekvenser.

Organisatorisk motstandskraft har stor betydning for LLM-applikasjoner

Selv om alle risikostyringsprogrammer kan dra nytte av motstandskraft, er organisatorisk robusthet vesentlig for generativ AI. Fem av de OWASP-identifiserte topp 10 risikoene for LLM-applikasjoner er avhengige av å definere arkitektoniske og operasjonelle kontroller og håndheve dem i en organisatorisk skala for å håndtere risiko. Disse fem risikoene er usikker produksjonshåndtering, sårbarheter i forsyningskjeden, avsløring av sensitiv informasjon, overdreven handlefrihet og overdreven tillit. Begynn å øke organisasjonens motstandskraft ved å sosialisere teamene dine for å vurdere AI, ML og generativ AI-sikkerhet som et kjernevirksomhetskrav og toppprioritet gjennom hele produktets livssyklus, fra idéstart, til forskning, til applikasjonens utvikling, distribusjon og bruk. I tillegg til bevissthet, bør teamene dine iverksette tiltak for å ta hensyn til generativ AI i styrings-, forsikrings- og samsvarsvalideringspraksis.

Bygg organisatorisk robusthet rundt generativ AI

Organisasjoner kan begynne å ta i bruk måter å bygge sin kapasitet og evner for AI/ML og generativ AI-sikkerhet i sine organisasjoner. Du bør begynne med å utvide dine eksisterende sikkerhets-, forsikrings-, samsvars- og utviklingsprogrammer for å ta hensyn til generativ AI.

Følgende er de fem nøkkelområdene av interesse for organisatorisk AI, ML og generativ AI-sikkerhet:

Forstå AI/ML-sikkerhetslandskapet
Inkluder ulike perspektiver i sikkerhetsstrategier
Ta handling proaktivt for å sikre forsknings- og utviklingsaktiviteter
Juster insentiver med organisatoriske resultater
Forbered deg på realistiske sikkerhetsscenarier i AI/ML og generativ AI

Utvikle en trusselmodell gjennom hele din generative AI-livssyklus

Organisasjoner som bygger med generativ AI bør fokusere på risikostyring, ikke risikoeliminering, og inkludere trusselmodellering i og forretningskontinuitetsplanlegging planlegging, utvikling og drift av generative AI-arbeidsmengder. Arbeid bakover fra produksjonsbruk av generativ AI ved å utvikle en trusselmodell for hver applikasjon ved å bruke tradisjonelle sikkerhetsrisikoer så vel som generative AI-spesifikke risikoer. Noen risikoer kan være akseptable for virksomheten din, og en trusselmodelleringsøvelse kan hjelpe bedriften din med å identifisere hva din akseptable risikovilje er. For eksempel kan det hende at bedriften din ikke krever 99.999 % oppetid på en generativ AI-applikasjon, så den ekstra gjenopprettingstiden knyttet til gjenoppretting ved å bruke AWS sikkerhetskopi med Amazon S3-breen kan være en akseptabel risiko. Omvendt kan dataene i modellen din være ekstremt sensitive og svært regulerte, så avvik fra AWS nøkkelstyringstjeneste (AWS KMS) kundeadministrert nøkkel (CMK) rotasjon og bruk av AWS nettverksbrannmur å hjelpe til med å håndheve Transport Layer Security (TLS) for inn- og utgående trafikk for å beskytte mot dataeksfiltrering kan være en uakseptabel risiko.

Vurder risikoen (iboende vs. gjenværende) ved å bruke den generative AI-applikasjonen i en produksjonssetting for å identifisere de riktige grunnleggende kontrollene og kontrollene på applikasjonsnivå. Planlegg for tilbakeføring og gjenoppretting fra produksjonssikkerhetshendelser og tjenesteavbrudd som umiddelbar injeksjon, opplæringsdataforgiftning, modellnekt og modelltyveri på et tidlig tidspunkt, og definer avgrensningene du vil bruke når du definerer applikasjonskrav. Å lære om risikoene og kontrollene som må på plass vil bidra til å definere den beste implementeringstilnærmingen for å bygge en generativ AI-applikasjon, og gi interessenter og beslutningstakere informasjon for å ta informerte forretningsbeslutninger om risiko. Hvis du ikke er kjent med den generelle AI- og ML-arbeidsflyten, start med å se gjennom 7 måter å forbedre sikkerheten for maskinlæringsarbeidsmengdene dine for å øke kjennskapen til sikkerhetskontrollene som trengs for tradisjonelle AI/ML-systemer.

Akkurat som å bygge en hvilken som helst ML-applikasjon, innebærer å bygge en generativ AI-applikasjon å gå gjennom et sett med forsknings- og utviklingsfaser. Det kan være lurt å gjennomgå AWS Generative AI Security Scoping Matrix å bidra til å bygge en mental modell for å forstå de viktigste sikkerhetsdisiplinene du bør vurdere avhengig av hvilken generativ AI-løsning du velger.

Generative AI-applikasjoner som bruker LLM-er, utvikles og drives vanligvis etter bestilte trinn:

Søknadskrav – Identifiser forretningsmål, krav og suksesskriterier for bruk
Modellvalg – Velg en grunnmodell som samsvarer med brukskravene
Modelltilpasning og finjustering – Forbered data, konstruer meldinger og finjuster modellen
Modellevaluering – Evaluer grunnlagsmodeller med bruk av case-spesifikke beregninger og velg den modellen som gir best resultater
Implementering og integrasjon – Distribuer den valgte grunnmodellen på den optimaliserte infrastrukturen og integrer med den generative AI-applikasjonen din
Applikasjonsovervåking – Overvåk applikasjons- og modellytelse for å muliggjøre rotårsaksanalyse

Sørg for at teamene forstår den kritiske naturen til sikkerhet som en del av design- og arkitekturfasene av livssyklusen for programvareutvikling på dag 1. Dette betyr å diskutere sikkerhet på hvert lag av stabelen og livssyklusen, og posisjonere sikkerhet og personvern som muliggjører for å oppnå forretningsmål. Arkitekt kontrollerer for trusler før du starter din LLM-applikasjon, og vurder om dataene og informasjonen du vil bruke til modelltilpasning og finjustering garanterer kontrollerer implementeringen i forsknings-, utviklings- og opplæringsmiljøene. Som en del av kvalitetssikringstester, introduser syntetiske sikkerhetstrusler (som forsøk på å forgifte treningsdata, eller forsøk på å trekke ut sensitive data gjennom ondsinnet prompt engineering) for å teste ut forsvaret og sikkerhetsstillingen med jevne mellomrom.

I tillegg bør interessenter etablere en konsistent gjennomgangskadens for produksjons-AI, ML og generative AI-arbeidsbelastninger og sette organisatoriske prioriteter på å forstå avveininger mellom menneskelig og maskinell kontroll og feil før lansering. Å validere og sikre at disse avveiningene blir respektert i de distribuerte LLM-applikasjonene vil øke sannsynligheten for suksess for risikoreduksjon.

Bygg generative AI-applikasjoner på sikre skyfundamenter

Hos AWS er sikkerhet vår toppprioritet. AWS er bygget for å være den sikreste globale skyinfrastrukturen for å bygge, migrere og administrere applikasjoner og arbeidsbelastninger. Dette støttes av vårt dype sett med over 300 skysikkerhetsverktøy og tilliten til våre millioner av kunder, inkludert de mest sikkerhetssensitive organisasjonene som myndigheter, helsevesen og finansielle tjenester. Når du bygger generative AI-applikasjoner ved å bruke LLM-er på AWS, får du sikkerhetsfordeler fra sikkert, pålitelig og fleksibelt AWS Cloud-databehandlingsmiljø.

Bruk en global AWS-infrastruktur for sikkerhet, personvern og samsvar

Når du utvikler dataintensive applikasjoner på AWS, kan du dra nytte av en global AWS-regionsinfrastruktur, utformet for å gi muligheter for å møte dine kjernekrav for sikkerhet og samsvar. Dette forsterkes av vår AWS Digital Suverenity Pledge, vår forpliktelse til å tilby deg det mest avanserte settet med suverenitetskontroller og funksjoner tilgjengelig i skyen. Vi er forpliktet til å utvide våre evner slik at du kan møte dine digital suverenitet behov, uten å gå på kompromiss med ytelsen, innovasjonen, sikkerheten eller skalaen til AWS Cloud. For å forenkle implementeringen av beste praksis for sikkerhet og personvern, bør du vurdere å bruke referansedesign og infrastruktur som koderessurser, for eksempel AWS Security Reference Architecture (AWS SRA) og AWS Privacy Reference Architecture (AWS PRA). Les mer om utforming av personvernløsninger, suverenitet ved designog overholdelse av AWS og bruke tjenester som f.eks AWS-konfig, AWS-artefaktog AWS revisjonssjef for å støtte dine behov for personvern, overholdelse, revisjon og observerbarhet.

Forstå sikkerhetsstillingen din ved å bruke AWS Well-Architected og Cloud Adoption Frameworks

AWS tilbyr veiledning for beste praksis utviklet fra mange års erfaring med å støtte kunder i å bygge deres skymiljøer med AWS godt arkitektert rammeverk og i å utvikle seg til å realisere forretningsverdi fra skyteknologier med AWS Cloud Adoption Framework (AWS CAF). Forstå sikkerhetsstillingen til AI-, ML- og generative AI-arbeidsbelastninger ved å utføre en gjennomgang av et godt arkitektonisk rammeverk. Vurderinger kan utføres ved hjelp av verktøy som AWS godt bygd verktøy, eller med hjelp av AWS-teamet ditt gjennom AWS Enterprise Support. AWS velarkitektte verktøy integrerer automatisk innsikt fra AWS Trusted Advisor for å evaluere hvilke beste praksiser som er på plass og hvilke muligheter som finnes for å forbedre funksjonalitet og kostnadsoptimalisering. AWS Well-Architected Tool tilbyr også tilpassede linser med spesifikke beste praksiser som Maskinlæringsobjektiv slik at du regelmessig kan måle arkitekturene dine mot beste praksis og identifisere områder for forbedring. Sjekk reisen din på veien til verdirealisering og skymodenhet ved å forstå hvordan AWS-kunder tar i bruk strategier for å utvikle organisasjonsevner i AWS Cloud Adoption Framework for kunstig intelligens, maskinlæring og generativ AI. Du kan også finne fordeler ved å forstå din generelle skyberedskap ved å delta i en AWS Cloud Readiness Assessment. AWS tilbyr flere muligheter for engasjement – spør AWS-kontoteamet ditt for mer informasjon om hvordan du kommer i gang med Generativt AI Innovasjonssenter.

Få fart på sikkerheten og AI/ML-læringen med veiledning, opplæring og sertifisering for beste praksis

AWS kuraterer også anbefalinger fra Beste praksis for sikkerhet, identitet og overholdelse og AWS sikkerhetsdokumentasjon for å hjelpe deg med å identifisere måter å sikre opplæring, utvikling, testing og driftsmiljøer på. Hvis du nettopp har begynt, dykk dypere på sikkerhetsopplæring og sertifisering, vurder å begynne med Grunnleggende om AWS-sikkerhet og AWS-sikkerhetslæringsplan. Du kan også bruke AWS sikkerhetsmodenhetsmodell for å hjelpe deg med å finne og prioritere de beste aktivitetene i ulike faser av modenhet på AWS, og starter med raske gevinster, gjennom grunnleggende, effektive og optimaliserte stadier. Etter at du og teamene dine har en grunnleggende forståelse av sikkerhet på AWS, anbefaler vi på det sterkeste å gå gjennom Hvordan nærme seg trusselmodellering og deretter lede en trusselmodelleringsøvelse med teamene dine som starter med Workshop for trusselmodellering for byggherrer treningsprogram. Det er mange andre AWS-sikkerhetstrenings- og sertifiseringsressurser tilgjengelig.

Bruk en dybdeforsvarstilnærming for å sikre LLM-applikasjoner

Å bruke en dyptgående sikkerhetstilnærming til generative AI-arbeidsbelastninger, data og informasjon kan bidra til å skape de beste forutsetningene for å nå forretningsmålene dine. Defens-in-depth sikkerhet beste praksis reduserer mange av de vanlige risikoene som enhver arbeidsbelastning står overfor, og hjelper deg og teamene dine med å akselerere din generative AI-innovasjon. En dyptgående sikkerhetsstrategi bruker flere redundante forsvar for å beskytte dine AWS-kontoer, arbeidsbelastninger, data og eiendeler. Det bidrar til å sikre at hvis en sikkerhetskontroll blir kompromittert eller svikter, finnes det flere lag for å hjelpe til med å isolere trusler og forhindre, oppdage, svare og gjenopprette fra sikkerhetshendelser. Du kan bruke en kombinasjon av strategier, inkludert AWS-tjenester og -løsninger, på hvert lag for å forbedre sikkerheten og motstandsdyktigheten til dine generative AI-arbeidsbelastninger.

Diagram over dyptgående sikkerhetslag

Mange AWS-kunder tilpasser seg industristandardrammeverk, for eksempel NIST Cybersecurity Framework. Dette rammeverket bidrar til å sikre at sikkerhetsforsvaret ditt har beskyttelse på tvers av pilarene Identify, Protect, Detect, Response, Recover, og sist lagt til, Govern. Dette rammeverket kan deretter enkelt kartlegges til AWS Security-tjenester og de fra integrerte tredjeparter, for å hjelpe deg med å validere tilstrekkelig dekning og retningslinjer for enhver sikkerhetshendelse organisasjonen din møter.

Forsvar i dybden: Sikre miljøet ditt, og legg deretter til forbedrede AI/ML-spesifikke sikkerhets- og personvernfunksjoner

En dybdeforsvarsstrategi bør starte med å beskytte kontoene og organisasjonen først, og deretter legge på de ekstra innebygde sikkerhets- og personvernforbedrede funksjonene til tjenester som f.eks. Amazonas grunnfjell og Amazon SageMaker. Amazon har over 30 tjenester i porteføljen for sikkerhet, identitet og samsvar som er integrert med AWS AI/ML-tjenester, og kan brukes sammen for å bidra til å sikre arbeidsbelastninger, kontoer og organisasjon. For å forsvare seg mot OWASP Topp 10 for LLM, bør disse brukes sammen med AWS AI/ML-tjenestene.

Start med å implementere en policy med minste privilegium, ved å bruke tjenester som IAM Access Analyzer til se etter altfor tillatte kontoer, roller og ressurser for å begrense tilgangen ved å bruke kortvarig legitimasjon. Deretter må du sørge for at alle data i hvile er kryptert med AWS KMS, inkludert å vurdere bruken av CMK-er, og at alle data og modeller er versjonert og sikkerhetskopiert med Amazon enkel lagringstjeneste (Amazon S3) versjonering og bruk av uforanderlighet på objektnivå med Amazon S3 Objektlås. Beskytt alle data i transitt mellom tjenester som bruker AWS Certificate Manager og / eller AWS Private CA, og hold den i VPC-er ved hjelp av AWS PrivateLink. Definer strenge regler for datainngang og -utgang for å beskytte mot manipulering og eksfiltrering ved bruk av VPCer med AWS nettverksbrannmur retningslinjer. Vurder å sette inn AWS Web Application Firewall (AWS WAF) foran til beskytte nettapplikasjoner og APIer fra ondsinnede roboter, SQL-injeksjonsangrep, cross-site scripting (XSS), og kontoovertakelser med Svindelkontroll. Logger med AWS CloudTrail, Amazon Virtual Private Cloud (Amazon VPC) flytlogger, og Amazon Elastic Kubernetes-tjeneste (Amazon EKS) revisjonslogger vil bidra til å gi rettsmedisinsk gjennomgang av hver transaksjon som er tilgjengelig for tjenester som Amazon -detektiv. Du kan bruke Amazon-inspektør å automatisere sårbarhetsoppdagelse og -administrasjon for Amazon Elastic Compute Cloud (Amazon EC2)-forekomster, containere, AWS Lambda funksjoner, og identifisere nettverkets tilgjengelighet for arbeidsbelastningene dine. Beskytt dataene og modellene dine mot mistenkelig aktivitet ved å bruke Amazon Guard Dutysine ML-drevne trusselmodeller og etterretningsfeeder, og aktiverer tilleggsfunksjonene for EKS Protection, ECS Protection, S3 Protection, RDS Protection, Malware Protection, Lambda Protection og mer. Du kan bruke tjenester som AWS Security Hub å sentralisere og automatisere sikkerhetskontrollene dine for å oppdage avvik fra beste praksis for sikkerhet og akselerere etterforskning og automatisere utbedring av sikkerhetsfunn med playbooks. Du kan også vurdere å implementere en null tillit arkitektur på AWS for ytterligere å øke finmaskede autentiserings- og autorisasjonskontroller for hva menneskelige brukere eller maskin-til-maskin-prosesser kan få tilgang til på forespørsel. Vurder også å bruke Amazon Security Lake for å automatisk sentralisere sikkerhetsdata fra AWS-miljøer, SaaS-leverandører, lokaler og skykilder til en spesialbygd datainnsjø som er lagret på kontoen din. Med Security Lake kan du få en mer fullstendig forståelse av sikkerhetsdataene dine på tvers av hele organisasjonen.

Etter at det generative AI-arbeidsmiljøet ditt er sikret, kan du legge lag på AI/ML-spesifikke funksjoner, som f.eks. Amazon SageMaker Data Wrangler å identifisere potensielle skjevheter under dataforberedelse og Amazon SageMaker Clarify for å oppdage skjevheter i ML-data og -modeller. Du kan også bruke Amazon SageMaker modellmonitor for å evaluere kvaliteten på SageMaker ML-modeller i produksjon, og varsle deg når det er avvik i datakvalitet, modellkvalitet og funksjonsattribusjon. Disse AWS AI/ML-tjenestene som jobber sammen (inkludert SageMaker som jobber med Amazon Bedrock) med AWS Security-tjenester kan hjelpe deg med å identifisere potensielle kilder til naturlig skjevhet og beskytte mot ondsinnet datatukling. Gjenta denne prosessen for hver av OWASP Topp 10 for LLM-sårbarhetene for å sikre at du maksimerer verdien av AWS-tjenester for å implementere forsvar i dybden for å beskytte data og arbeidsbelastninger.

Som AWS Enterprise Strategist Clarke Rodgers skrev i sitt blogginnlegg "CISO Insight: Hver AWS-tjeneste er en sikkerhetstjeneste", "Jeg vil hevde at praktisk talt hver tjeneste innenfor AWS-skyen enten muliggjør et sikkerhetsresultat i seg selv, eller kan brukes (alene eller sammen med en eller flere tjenester) av kunder for å oppnå et sikkerhets-, risiko- eller samsvarsmål." Og "Customer Chief Information Security Officers (CISOer) (eller deres respektive team) vil kanskje ta seg tid til å sikre at de er godt kjent med alle AWS-tjenester fordi det kan være et sikkerhets-, risiko- eller samsvarsmål som kan oppfylles, selv om en tjeneste ikke faller inn under kategorien "Sikkerhet, identitet og overholdelse".

Lag forsvar ved tillitsgrenser i LLM-applikasjoner

Når du utvikler generative AI-baserte systemer og applikasjoner, bør du vurdere de samme bekymringene som med alle andre ML-applikasjoner, som nevnt i MITRE ATLAS Machine Learning Threat Matrix, for eksempel å være oppmerksom på opprinnelsen til programvare og datakomponenter (som å utføre en åpen kildekode-programvarerevisjon, gjennomgå programvarefortegnelser og analysere dataarbeidsflyter og API-integrasjoner) og implementere nødvendig beskyttelse mot LLM-forsyningskjedenstrusler. Inkluder innsikt fra bransjerammeverk, og vær oppmerksom på måter å bruke flere kilder til trusselintelligens og risikoinformasjon for å justere og utvide sikkerhetsforsvaret ditt for å ta hensyn til AI, ML og generative AI-sikkerhetsrisikoer som dukker opp og ikke er inkludert i tradisjonelle rammeverk. Søk etter ledsagerinformasjon om AI-spesifikke risikoer fra industri, forsvar, statlige, internasjonale og akademiske kilder, fordi nye trusler dukker opp og utvikler seg i dette området regelmessig, og følgerammeverk og guider oppdateres ofte. For eksempel, når du bruker en Retrieval Augmented Generation (RAG)-modell, hvis modellen ikke inkluderer dataene den trenger, kan den be om det fra en ekstern datakilde for bruk under inferencing og finjustering. Kilden den spør etter kan være utenfor din kontroll, og kan være en potensiell kilde til kompromiss i forsyningskjeden din. En dyptgående forsvarstilnærming bør utvides mot eksterne kilder for å etablere tillit, autentisering, autorisasjon, tilgang, sikkerhet, personvern og nøyaktighet av dataene den får tilgang til. For å dykke dypere, les "Bygg en sikker bedriftsapplikasjon med Generative AI og RAG ved å bruke Amazon SageMaker JumpStart"

Analyser og reduser risiko i LLM-applikasjonene dine

I denne delen analyserer og diskuterer vi noen risikoreduserende teknikker basert på tillitsgrenser og interaksjoner, eller distinkte områder av arbeidsbelastningen med tilsvarende passende kontrollomfang og risikoprofil. I denne eksempelarkitekturen til en chatbot-applikasjon er det fem tillitsgrenser der kontroller demonstreres, basert på hvordan AWS-kunder vanligvis bygger sine LLM-applikasjoner. LLM-applikasjonen din kan ha flere eller færre definerbare tillitsgrenser. I følgende eksempelarkitektur er disse tillitsgrensene definert som:

Brukergrensesnittinteraksjoner (forespørsel og svar)
Applikasjonsinteraksjoner
Modellinteraksjoner
Datainteraksjoner
Organisatoriske interaksjoner og bruk

Brukergrensesnittinteraksjoner: Utvikle forespørsels- og responsovervåking

Oppdag og reager på cyberhendelser relatert til generativ AI på en rettidig måte ved å evaluere en strategi for å håndtere risiko fra input og output fra den generative AI-applikasjonen. For eksempel kan det være nødvendig med ytterligere overvåking for atferd og datautstrømning for å oppdage avsløring av sensitiv informasjon utenfor domenet eller organisasjonen din, i tilfelle den brukes i LLM-applikasjonen.

Generative AI-applikasjoner bør fortsatt opprettholde standard sikkerhetspraksis når det gjelder å beskytte data. Etablere en sikker dataomkrets og sikre sensitive datalagre. Krypter data og informasjon brukt for LLM-applikasjoner i hvile og under transport. Beskytt data som brukes til å trene modellen din mot å trene dataforgiftning ved å forstå og kontrollere hvilke brukere, prosesser og roller som har lov til å bidra til datalagrene, samt hvordan dataflyter i applikasjonen, overvåke for skjevhetsavvik og bruke versjons- og uforanderlig lagring i lagringstjenester som Amazon S3. Etabler strenge kontroller for datainngang og -utgang ved å bruke tjenester som AWS Network Firewall og AWS VPC-er for å beskytte mot mistenkelig inndata og potensialet for dataeksfiltrering.

Under opplærings-, omskolerings- eller finjusteringsprosessen bør du være oppmerksom på eventuelle sensitive data som brukes. Etter at data er brukt under en av disse prosessene, bør du planlegge for et scenario der enhver bruker av modellen din plutselig blir i stand til å trekke ut dataene eller informasjonen tilbake ved å bruke raske injeksjonsteknikker. Forstå risikoene og fordelene ved å bruke sensitive data i modellene dine og slutninger. Implementer robuste autentiserings- og autorisasjonsmekanismer for å etablere og administrere finmaskede tilgangstillatelser, som ikke er avhengige av LLM-applikasjonslogikk for å forhindre avsløring. Brukerkontrollert input til en generativ AI-applikasjon har blitt demonstrert under noen forhold for å kunne gi en vektor for å trekke ut informasjon fra modellen eller eventuelle ikke-brukerkontrollerte deler av input. Dette kan skje via umiddelbar injeksjon, der brukeren gir input som får utdataene til modellen til å avvike fra de forventede rekkverkene til LLM-applikasjonen, inkludert å gi ledetråder til datasettene som modellen opprinnelig ble trent på.

Implementer tilgangskvoter på brukernivå for brukere som gir input og mottar utdata fra en modell. Du bør vurdere tilnærminger som ikke tillater anonym tilgang under forhold der modellens treningsdata og informasjon er sensitive, eller der det er risiko fra en motstander som trener en faksimile av modellen din basert på deres input og din justerte modellutgang. Generelt, hvis en del av input til en modell består av vilkårlig brukerlevert tekst, bør du vurdere utdataene som mottakelige for umiddelbar injeksjon, og følgelig sikre at bruken av utdataene inkluderer implementerte tekniske og organisatoriske mottiltak for å redusere usikker utdatahåndtering, overdreven byråkrati og overdreven tillit. I eksemplet tidligere relatert til filtrering for ondsinnet input ved bruk av AWS WAF, bør du vurdere å bygge et filter foran applikasjonen din for slik potensiell misbruk av forespørsler, og utvikle en policy for hvordan du skal håndtere og utvikle disse etter hvert som modellen og dataene dine vokser. Vurder også en filtrert gjennomgang av utdata før det returneres til brukeren for å sikre at det oppfyller standarder for kvalitet, nøyaktighet eller innholdsmoderering. Det kan være lurt å tilpasse dette ytterligere for organisasjonens behov med et ekstra lag med kontroll på innganger og utganger foran modellene dine for å redusere mistenkelige trafikkmønstre.

Applikasjonsinteraksjoner: Applikasjonssikkerhet og observerbarhet

Se gjennom LLM-applikasjonen din med oppmerksomhet på hvordan en bruker kan bruke modellen din til å omgå standard autorisasjon til et nedstrømsverktøy eller verktøykjede som de ikke har autorisasjon til å få tilgang til eller bruke. En annen bekymring på dette laget involverer tilgang til eksterne datalagre ved å bruke en modell som en angrepsmekanisme ved å bruke ubegrensede tekniske eller organisatoriske LLM-risikoer. For eksempel, hvis modellen din er opplært til å få tilgang til visse datalagre som kan inneholde sensitive data, bør du sørge for at du har riktige autorisasjonssjekker mellom modellen og datalagrene. Bruk uforanderlige attributter om brukere som ikke kommer fra modellen når du utfører autorisasjonssjekker. Ubegrenset, usikker utdatahåndtering, usikker plugin-design og overdreven byrå kan skape forhold der en trusselaktør kan bruke en modell for å lure autorisasjonssystemet til å eskalere effektive privilegier, noe som fører til en nedstrømskomponent som tror at brukeren er autorisert til å hente data eller ta en spesifikk handling.

Når du implementerer et generativt AI-plugin eller verktøy, er det viktig å undersøke og forstå tilgangsnivået som gis, samt granske tilgangskontrollene som er konfigurert. Bruk av ubegrenset usikre generative AI-plugins kan gjøre systemet ditt mottakelig for forsyningskjedesårbarheter og trusler, som potensielt kan føre til ondsinnede handlinger, inkludert kjøring av ekstern kode.

Modellinteraksjoner: Forebygging av modellangrep

Du bør være klar over opprinnelsen til alle modeller, plugins, verktøy eller data du bruker, for å evaluere og redusere sårbarheter i forsyningskjeden. For eksempel tillater noen vanlige modellformater innbygging av vilkårlig kjørbar kode i selve modellene. Bruk pakkespeil, skanning og ekstra inspeksjoner som er relevant for organisasjonens sikkerhetsmål.

Datasettene du trener og finjusterer modellene dine på må også gjennomgås. Hvis du ytterligere automatisk finjusterer en modell basert på tilbakemeldinger fra brukere (eller annen sluttbrukerkontrollerbar informasjon), må du vurdere om en ondsinnet trusselaktør kan endre modellen vilkårlig basert på å manipulere svarene deres og oppnå forgiftning av treningsdata.

Datainteraksjoner: Overvåk datakvalitet og bruk

Generative AI-modeller som LLM-er fungerer generelt bra fordi de har blitt trent på en stor mengde data. Selv om disse dataene hjelper LLM-er med å fullføre komplekse oppgaver, kan de også utsette systemet for risiko for treningsdataforgiftning, som oppstår når upassende data inkluderes eller utelates i et treningsdatasett som kan endre en modells atferd. For å redusere denne risikoen bør du se på forsyningskjeden din og forstå datagjennomgangsprosessen for systemet ditt før det brukes i modellen din. Selv om treningsrørledningen er en hovedkilde for dataforgiftning, bør du også se på hvordan modellen din får data, for eksempel i en RAG-modell eller datainnsjø, og om kilden til disse dataene er klarert og beskyttet. Bruk AWS Security-tjenester som AWS Security Hub, Amazon GuardDuty og Amazon Inspector for å hjelpe kontinuerlig overvåke for mistenkelig aktivitet i Amazon EC2, Amazon EKS, Amazon S3, Amazon Relational Database Service (Amazon RDS), og nettverkstilgang som kan være indikatorer på nye trusler, og bruk Detective til å visualisere sikkerhetsundersøkelser. Vurder også å bruke tjenester som f.eks Amazon Security Lake å akselerere sikkerhetsundersøkelser ved å lage en spesialbygd datainnsjø for å automatisk sentralisere sikkerhetsdata fra AWS-miljøer, SaaS-leverandører, lokaler og skykilder som bidrar til AI/ML-arbeidsbelastningene dine.

Organisatoriske interaksjoner: Implementer rekkverk for virksomhetsstyring for generativ AI

Identifiser risiko forbundet med bruk av generativ AI for virksomhetene dine. Du bør bygge organisasjonens risikotaksonomi og gjennomføre risikovurderinger for å ta informerte beslutninger når du implementerer generative AI-løsninger. Utvikle en forretningskontinuitetsplan (BCP) som inkluderer AI-, ML- og generative AI-arbeidsbelastninger og som kan vedtas raskt for å erstatte den tapte funksjonaliteten til en påvirket eller offline LLM-applikasjon for å oppfylle SLAene dine.

Identifiser prosess- og ressurshull, ineffektivitet og inkonsekvenser, og forbedre bevisstheten og eierskapet på tvers av virksomheten din. Trusselmodell alle generative AI-arbeidsbelastninger for å identifisere og redusere potensielle sikkerhetstrusler som kan føre til forretningspåvirkende resultater, inkludert uautorisert tilgang til data, tjenestenekt og ressursmisbruk. Dra nytte av det nye AWS Threat Composer Modeling Tool for å redusere tid til verdi når du utfører trusselmodellering. Senere i utviklingssyklusene dine, vurder å inkludere å introdusere sikkerhet kaos engineering feilinjeksjonseksperimenter for å skape virkelige forhold for å forstå hvordan systemet ditt vil reagere på ukjente og bygge tillit til systemets motstandskraft og sikkerhet.

Inkluder ulike perspektiver i utviklingen av sikkerhetsstrategier og risikostyringsmekanismer for å sikre overholdelse og dekning for AI/ML og generativ sikkerhet på tvers av alle jobbroller og funksjoner. Ta med en sikkerhetstankegang til bordet fra starten og forskningen av enhver generativ AI-applikasjon for å tilpasse seg kravene. Hvis du trenger ekstra assistanse fra AWS, be AWS-kontoadministratoren din om å sørge for at det er lik støtte ved å be AWS Solutions Architects fra AWS Security og AI/ML om å hjelpe til.

Sørg for at sikkerhetsorganisasjonen din rutinemessig iverksetter tiltak for å fremme kommunikasjon rundt både risikobevissthet og risikostyringsforståelse blant generative AI-interessenter som produktsjefer, programvareutviklere, datavitere og utøvende ledelse, slik at trusselintelligens og kontrollveiledning kan nå teamene som kan bli påvirket. Sikkerhetsorganisasjoner kan støtte en kultur med ansvarlig avsløring og iterativ forbedring ved å delta i diskusjoner og bringe nye ideer og informasjon til generative AI-interessenter som er relatert til deres forretningsmål. Lære mer om vår forpliktelse til ansvarlig kunstig intelligens og ytterligere ansvarlige AI-ressurser for å hjelpe våre kunder.

Få fordeler ved å muliggjøre bedre organisasjonsholdning for generativ AI ved å fjerne blokkering av tid til verdi i de eksisterende sikkerhetsprosessene i organisasjonen din. Evaluer proaktivt hvor organisasjonen din kan kreve prosesser som er altfor byrdefulle gitt den generative AI-sikkerhetskonteksten, og avgrens disse for å gi utviklere og forskere en klar vei til lansering med de riktige kontrollene på plass.

Vurder hvor det kan være muligheter for å samordne insentiver, forringe, og gi en klar sikte på de ønskede resultatene. Oppdatering kontrollerer veiledning og forsvar for å møte de utviklende behovene til AI/ML og generativ AI-applikasjonsutvikling for å redusere forvirring og usikkerhet som kan koste utviklingstid, øke risikoen og øke effekten.

Sikre at interessenter som ikke er sikkerhetseksperter er i stand til både å forstå hvordan organisasjonsstyring, policyer og risikostyringstrinn gjelder for deres arbeidsbelastninger, samt anvende risikostyringsmekanismer. Forbered organisasjonen din til å svare på realistiske hendelser og scenarier som kan oppstå med generative AI-applikasjoner, og sørg for at generative AI-byggerroller og responsteam er klar over eskaleringsbaner og handlinger i tilfelle bekymring for mistenkelig aktivitet.

konklusjonen

For å lykkes med kommersialisering av innovasjon med enhver ny og fremvoksende teknologi, kreves det at man starter med en sikkerhet-først-tankegang, bygger på et sikkert infrastrukturfundament, og tenker på hvordan man kan integrere sikkerhet på hvert nivå av teknologistabelen tidlig med en dyptgående sikkerhet. nærme seg. Dette inkluderer interaksjoner på flere lag av teknologistabelen din, og integrasjonspunkter i din digitale forsyningskjede, for å sikre organisasjonsmessig robusthet. Selv om generativ AI introduserer noen nye sikkerhets- og personvernutfordringer, hvis du følger grunnleggende sikkerhetspraksis som å bruke dybdeforsvar med lagdelte sikkerhetstjenester, kan du bidra til å beskytte organisasjonen din mot mange vanlige problemer og nye trusler. Du bør implementere lagdelte AWS-sikkerhetstjenester på tvers av generative AI-arbeidsbelastninger og større organisasjon, og fokusere på integreringspunkter i dine digitale forsyningskjeder for å sikre skymiljøene dine. Deretter kan du bruke de forbedrede sikkerhets- og personvernfunksjonene i AWS AI/ML-tjenester som Amazon SageMaker og Amazon Bedrock for å legge til flere lag med forbedret sikkerhet og personvernkontroller til dine generative AI-applikasjoner. Innbygging av sikkerhet fra starten vil gjøre det raskere, enklere og mer kostnadseffektivt å innovere med generativ AI, samtidig som det forenkler overholdelse. Dette vil hjelpe deg med å øke kontrollene, tilliten og observerbarheten til dine generative AI-applikasjoner for dine ansatte, kunder, partnere, regulatorer og andre berørte interessenter.

Ytterligere referanser

Bransjestandardrammeverk for AI/ML-spesifikk risikostyring og sikkerhet:

Om forfatterne

Christopher Rae er en verdensledende GTM-spesialist med fokus på å utvikle og gjennomføre strategiske initiativer som akselererer og skalerer innføringen av AWS-sikkerhetstjenester. Han er lidenskapelig opptatt av skjæringspunktet mellom cybersikkerhet og nye teknologier, med 20+ års erfaring i globale strategiske lederroller som leverer sikkerhetsløsninger til medie-, underholdnings- og telekomkunder. Han lades opp gjennom lesing, reiser, mat og vin, oppdage ny musikk og gi råd til startups i tidlige stadier.

Elijah Winter er en senior sikkerhetsingeniør i Amazon Security, med en BS i cybersikkerhetsteknikk og full av kjærlighet til Harry Potter. Elijah utmerker seg i å identifisere og adressere sårbarheter i AI-systemer, og blander teknisk ekspertise med et snev av trolldom. Elijah designer skreddersydde sikkerhetsprotokoller for AI-økosystemer, og gir digitalt forsvar en magisk teft. Elijah er drevet av integritet og har sikkerhetsbakgrunn i både offentlige og kommersielle organisasjoner med fokus på å beskytte tillit.

Ram Vittal er en rektor ML Solutions Architect ved AWS. Han har over 3 tiår med erfaring med å bygge og bygge distribuerte, hybride og skyapplikasjoner. Han brenner for å bygge sikre og skalerbare AI/ML- og big data-løsninger for å hjelpe bedriftskunder med deres skyadopsjon og optimaliseringsreise for å forbedre forretningsresultatene deres. På fritiden kjører han motorsykkel og går tur med sin 3 år gamle Sheepadoodle!

Navneet Tuteja er dataspesialist hos Amazon Web Services. Før han begynte i AWS, jobbet Navneet som en tilrettelegger for organisasjoner som ønsket å modernisere dataarkitekturene sine og implementere omfattende AI/ML-løsninger. Hun har en ingeniørgrad fra Thapar University, samt en mastergrad i statistikk fra Texas A&M University.

Emily Soward er en dataforsker med AWS Professional Services. Hun har en Master of Science with Distinction in Artificial Intelligence fra University of Edinburgh i Skottland, Storbritannia med vekt på Natural Language Processing (NLP). Emily har tjent i anvendte vitenskapelige og ingeniørroller med fokus på AI-aktivert produktforskning og -utvikling, operasjonell fortreffelighet og styring for AI-arbeidsmengder som kjører i organisasjoner i offentlig og privat sektor. Hun bidrar til kundeveiledning som AWS Senior Speaker og nylig som forfatter for AWS Well-Architected in the Machine Learning Lens.

SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
kilde: https://aws.amazon.com/blogs/machine-learning/architect-defense-in-depth-security-for-generative-ai-applications-using-the-owasp-top-10-for-llms/

Generativ dataintelligens

Arkitekt forsvar og dybdesikkerhet for generative AI-applikasjoner ved å bruke OWASP Topp 10 for LLMs | Amazon Web Services