Hogyan helyezhetnek üzembe a pénzügyi csapatok AI-val készített alkalmazásokat pénzügyi adatszivárgás nélkül?

Amikor a RedAccess biztonsági cég AI-alapú kódolóeszközökkel készített, az eszközök saját tárhelyén közzétett alkalmazásokat keresett, több mint 5 000 olyat talált, amelyben szinte semmilyen biztonság vagy hitelesítés nem volt. A Wirednek megmutatott képernyők között „különféle más vállalatok vegyes értékesítési és pénzügyi nyilvántartásai” is szerepeltek. A pénzügyi csapatok AI-val készített alkalmazásai ugyanilyen nyitott címen köthetnek ki, mögöttük a főkönyvvel, béradatokkal és még be nem jelentett eredményekkel.

A Replit vezérigazgatója, Amjad Masad azt válaszolta, hogy „A nyilvános alkalmazások internetes elérhetősége elvárt működés”. A mechanizmust illetően igaza van. Az én értelmezésem szerint a kitettséget egy láthatósági beállítás és egy kihagyott ellenőrzés okozta; mindkettő az eszköz készítőjének hatáskörében van.

Röviden

• Egy AI-val készített pénzügyi eszköz hat üzembe helyezési hibán keresztül szivárogtathat adatot, és mindegyiket kezelheti a készítője: nyilvános hivatkozás, a kódban vagy csevegési előzményekben hagyott jelszavak és kulcsok, rendszergazdai adatbázis-hozzáférés, könyvelés második jóváhagyó nélkül, külső szolgáltatásoknak küldött adatok, valamint senki által nem rögzített számításmódosítások.
• Minden hibához tartozik javítás, többnyire ugyanazzal az AI-eszközzel alkalmazható, amely az alkalmazást készítette, és egy egyszerű ellenőrzés, amely bizonyítja a javítás működését: például az adatbázis által elutasított írás vagy a többé nem működő régi jelszó.
• Alapértelmezésben tartsd a pénzügyi eszközt magánhálózaton, adj hozzá vállalati bejelentkezést, amikor a pénzügyön kívüli személyeknek is szükségük van rá, és add át az IT-nak, ha második jóváhagyó nélkül könyvel, kártyaadatokat érint, vagy SOX hatálya alá tartozó pénzügyi kimutatásokhoz szolgáltat számokat.
• A kiszolgáló régiója meghatározza az alkalmazás elsődleges VPS-tárolójának helyét, de a biztonsági mentések, naplók és külső szolgáltatások máshol is létrehozhatnak másolatokat; a teljes rendszer megfelelősége külön kérdés. Vidd el a régiódra vonatkozó keretrendszereket a megfelelőségi csapatnak.

A pénzügyi adatokat kiszivárogtató üzembe helyezési hibák

Egy AI-val készített pénzügyi eszköz hat üzembe helyezési hibán keresztül szivárogtathat adatot: nyilvános hivatkozáson hagyják, hitelesítő adatokat tartanak a kódban vagy csevegésben, rendszergazdai hozzáféréssel kapcsolódnak, amikor az olvasás is elegendő, második jóváhagyó nélkül könyvelnek, külső szolgáltatásoknak küldenek pénzügyi adatokat, és nyilvántartás nélkül módosítják a számításokat. Mindegyik olyan alapbeállítás, amelyet a bemutató előnyben részesít.

Minden alábbi javításhoz tartozik egy utasítás az alkalmazást készítő AI-eszköz számára; a bemásolás előtt módosítsd a szögletes zárójelek közötti mezőket. Ezek a cikkhez írt, nem tesztelt kiindulópontok, és semmit nem bizonyít, ha az AI-eszköz azt állítja, hogy módosított valamit. Az utasítás alatti ellenőrzés a bizonyíték. Az utasításokat a kódon és minta- vagy szintetikus adatokon futtasd, és soha ne másolj valódi rekordokat vagy éles kulcsokat a csevegésbe.

Az eszköz az AI-készítő nyilvános hivatkozásán marad

Az AI-készítő tárhelyén nyilvánosan hagyott cashflow-előrejelző irányítópultot bárki megnyithatja, aki ismeri a címét, és mindent láthat, amit az mutat: szállítói tartozások korosítását, terv-tény összevetést, a negyedév még be nem jelentett eredményeit. A Wired beszámolója a RedAccess eredményeiről leírja, hogy a kutatók egyszerű Google- és Bing-keresésekkel találták meg ezeket az alkalmazásokat az AI-szolgáltatók domainjein.

Néhány ilyen alkalmazás csak azt kérte, hogy a látogató bármilyen e-mail-címmel jelentkezzen be. A bármilyen e-mail-címet elfogadó bejelentkezés nem hozzáférés-szabályozás.

Távolítsd el az éles adatokat a szolgáltató tárhelyéről. Amíg az eszköz nem az általad ellenőrzött kiszolgálón fut (a következő szakasz tárgyalja, hol), szintetikus adatokkal vagy az ERP tesztkörnyezetével, illetve tesztvállalatával fejleszd és mutasd be, ha van ilyen; soha ne éles exporttal. A módosítás után helyezd ismét üzembe, mert a hosztolt cím a legutóbb üzembe helyezett verziót szolgálja ki.

Készíts ehhez az alkalmazáshoz szintetikus adatkészletet az általa olvasott tábláknak és oszlopoknak megfelelően: [sorold fel a táblákat és oszlopokat, például vendors, invoices, journal_lines].

Használj kitalált szállító- és ügyfélneveket, kitalált bankszámlaszámokat és [pénznem] összegeket, amelyek valódi könyvelésként viselkednek: minden naplótétel legyen egyensúlyban, és az analitika összegei egyezzenek [a szállítói / vevői gyűjtőszámlával].

Az alkalmazást erre az adatkészletre irányítsd bármilyen éles export helyett, és sorold fel az összes módosított fájlt vagy beállítást.

Ne kérj tőlem valódi rekordokat.

Ellenőrizd, hogy működött: nyisd meg a szolgáltatónál hosztolt címet kijelentkezett böngészőben, vagy kérj meg erre egy pénzügyön kívüli kollégát, és igazold, hogy csak szintetikus adatot, bejelentkezési falat vagy semmit nem mutat. Ezután keress az alkalmazás adatfájljaiban és a kódtárban három, az éles ERP-ből vett szállító- vagy ügyfélnevet; nem lehet találat. Végül futtasd az alkalmazás főkönyvi kivonatát vagy összesítő nézetét, és ellenőrizd, hogy az összes Tartozik egyenlő az összes Követellel.

ERP-, banki adatkapcsolati és adatbázis-hitelesítő adatok maradnak a kódban vagy csevegésben

Ha ott éles hitelesítő adatot tárolnak, bárki, aki olvasni tudja a csevegési előzményeket, a kódtárat vagy az MCP konfigurációs fájlját, esetleg az ERP, a pénzügyi adatbázis vagy a banki adatkapcsolat elérésére is használhatja azt. Az MCP az összekötő, amely lehetővé teszi, hogy egy AI-eszköz, például a Claude közvetlenül kommunikáljon az ERP-vel vagy egy adatbázissal; konfigurációs fájlja egy újabb hely, ahol jelszó lehet.

A GitGuardian State of Secrets Sprawl 2026 jelentése 24 008 egyedi, MCP konfigurációs fájlokban kiszivárgott titkot talált, amelyek 14%-a PostgreSQL adatbázis-kapcsolati karakterlánc volt. A nyilvános GitHub-commitok között ugyanez a jelentés a Claude Code társszerzőségével készült commitoknál a kiindulási arány körülbelül kétszeresét találta a titokszivárgásokban, és hozzáteszi, hogy az emberi tényező is kritikus marad.

A csevegési üzenet törlése nem szünteti meg a kitettséget: akinek van másolata a csevegésről, a kódtárról vagy annak előzményeiről, annál megmarad az érték. Minden jelszóhoz, kulcshoz vagy tokenhez, amely valaha ilyen helyen volt, adj ki újat az ERP, az adatbázis vagy a banki adatkapcsolat adminisztrációs felületén, és tiltsd le a régit. Ezt jelenti a hitelesítő adatok rotálása.

Az alkalmazás ezután induláskor környezeti változókból (a kódon kívül tartott, névvel ellátott beállításokból) olvassa a hitelesítő adatait. Ezeket az üzembe helyezési réteg szolgáltatja, amely az alkalmazást a kiszolgálón összeállítja és futtatja. A HashiCorp Vault a következő lépés, amikor több eszköz osztozik a titkokon, és egy helyről kell rotálni őket.

A csapat saját jelszómásolatai embereknek tervezett jelszókezelőbe, például a Vaultwarden rendszerébe valók; a futó alkalmazás a környezetből olvassa az értékeit. Kezdd az AI által létrehozott kód összes közvetlenül beírt titkának megkeresésével.

Vizsgáld át ezt a projektet közvetlenül beírt titkok után. Találj meg minden jelszót, API-kulcsot, hozzáférési tokent és kapcsolati karakterláncot, a .env fájlokban, notebookokban, MCP konfigurációs fájlokban és a [ERP neve / banki adatkapcsolat szolgáltatója / pénzügyi adatbázis] kapcsolódó kódjában is.

Cserélj ki minden értéket a kódban névvel ellátott környezeti változóra, és add meg a változónevek listáját.

Gondoskodj arról, hogy valódi értéket tartalmazó fájl ne kerüljön commitba a kódtárban, és sorolj fel minden commitot a kódtár előzményeiben, ahol valamelyik érték megjelenik.

Csak a helyeket mutasd meg. Egyetlen titkos értéket se írj ki.

Ellenőrizd, hogy működött: próbáld ki magad a régi jelszót vagy tokent, vagy kérd meg erre az IT-t; elutasítást várj. Ezután keresd a jelenlegi projektfájlokban a régi értékeket; nem lehet találat. Az előzményekben maradt találat csak akkor nem biztosít többé hozzáférést, ha igazoltad, hogy az értéket visszavonták vagy lejárt.

Kapcsolódás a készítő rendszergazdai fiókjával, amikor csak olvasás kell

A vevői követelések korosítását mutató irányítópult nem módosíthatja a főkönyvet. Ha az eszköz a készítő rendszergazdai fiókjával kapcsolódik, örökli annak jogosultságait. A Supabase titkos kulcsa vagy a régi service_role kulcs emelt szintű hozzáférést ad a projekt adataihoz, és megkerüli a Row Level Securityt, ezért nem használható szokásos, csak olvasásra szolgáló hozzáféréshez. Egyetlen korosítási kimutatáshoz készült jelentés így a teljes főkönyvet elérhetővé teszi, a bértáblákkal együtt.

Az írási oldalon válik ez költségessé. A Symbiotic Security 1 072 AI-val készített alkalmazást vizsgáló elemzése a Supabase-alapú alkalmazások között 172 olyat talált, amelyben bárki törölhetett rekordokat hitelesítés nélkül, 172 olyat, amelyben bárki módosíthatott meglévő rekordokat, és 39 olyat, amelynek tábláit a nyilvános kulcs birtokában bárki teljesen olvashatta.

Adj az eszköznek csak olvasásra szolgáló hitelesítő adatot, az általa olvasott táblákra korlátozva. Az ERP-ben vagy adatbázisban ez dedikált integrációs felhasználót jelent: az eszköz számára létrehozott külön fiókot, amely csak a jelentéshez szükséges objektumokat olvashatja. A Supabase-ben kapcsold be a Row Level Securityt (azt az adatbázisszabályt, amely meghatározza, hogy az egyes kérések mely sorokat láthatják) minden, az eszköz által használt, elérhetővé tett táblánál, és ellenőrizd a táblajogosultságokat is: ezek döntik el, hogy egy szerepkör egyáltalán végezhet-e select, insert, update vagy delete műveletet. A csak olvasó pénzügyi alkalmazás szerepkörének ne legyen szükségtelen írási joga. A publishable kulcs lehet a böngészőkódban, ha az RLS és a minimálisan szükséges jogosultságok helyesek. A titkos és a régi service_role kulcsok maradjanak a kiszolgálón; valóban emelt hozzáférést igénylő, saját jogosultságellenőrzést végző háttérfeladatokhoz tartoznak.

Megjegyzés: A Supabase publishable kulcsa vagy a régi anon kulcs normálisan látható lehet az oldal JavaScriptjében. A Supabase API-kulcsokról szóló dokumentációja szerint csak ahhoz fér hozzá, amit a Row Level Security engedélyez. A titkos kulcs megkerüli a Row Level Securityt, ezért soha nem jelenhet meg semmiben, amit böngészőnek küldenek.

Sorold fel az alkalmazás minden olvasását és írását a [ERP vagy adatbázis neve] rendszerben, táblánként vagy objektumonként csoportosítva.

Módosítsd az alkalmazást úgy, hogy csak [a szükséges táblákat] olvassa, és külön, környezeti változóból kapott, csak olvasásra szolgáló hitelesítő adattal kapcsolódjon, soha ne az én fiókommal.

Ha az alkalmazás Supabase-t használ: kapcsold be a Row Level Securityt minden elérhetővé tett táblánál, amelyet érint. Sorold fel az anon és authenticated szerepkörök select, insert, update és delete jogosultságait. Ennél a csak olvasó alkalmazásnál távolítsd el a nem szükséges írási jogosultságokat; ha egy másik éles alkalmazás valamelyiktől függ, módosítás helyett jelezd. Ezután írj szabályokat, hogy a kijelentkezett látogatók semmit ne olvashassanak, a bejelentkezett felhasználók pedig csak a következőt olvashassák: [szabály, például saját költséghelyük sorai]. Ellenőrizd, hogy a böngészőnek küldött egyetlen fájlban sincs titkos vagy régi service_role kulcs.

Sorold fel a létrehozott szabályokat.

Ellenőrizd, hogy működött: az eszköz hitelesítő adatával próbálj egy írást, például tesztrekord-módosítást; elutasítást várj. Supabase esetén kérd egy pénzügyi tábla sorait kijelentkezve; üres eredményt vagy hibát várj.

Az eszköz második jóváhagyó nélkül könyvelhet

A közvetlenül könyvelő naplótétel-importáló vagy a fájlt közvetlenül a banknak küldő fizetésifájl-generátor a futtatót egyszerre teszi előkészítővé és jóváhagyóvá. Egyetlen hiba megdupláz egyhavi elhatárolást. Egyetlen módosított mező rossz számlára küldi a szállítói fizetést. Ez ugyanaz a feladat-elválasztási sérülés, amelyet a pénzügy két ember között sem enged meg, és az AI-asszisztenssel készített szoftver sem kivétel.

A kár nem marad az alkalmazásban. A hibás köteg a könyvekbe kerül, ahol visszafordításához helyesbítő tétel és záráskori magyarázat kell. Ha az eszköz a készítő saját fiókjával könyvel, minden megduplázott tétel a készítő nevét viseli.

Az AI-val készített eszköz olvas és előkészít; a könyvelés és a fizetés engedélyezése az ERP saját jóváhagyási folyamatában történik, az eszköz futtatójától eltérő személy jóváhagyásával. Minden számviteli rendszer, amelyen dolgoztam, a tételt és a jóváhagyását két eseményként, két felelőssel kezeli; az AI-val készített eszköz is ezt érdemli.

A gyakorlatban minden közvetlen könyvelést alakíts át vázlattétellé vagy előkészített importtá, amely az ERP-ben vár jóváhagyásra. Az eszköz továbbra is elvégzi az unalmas részt (mezőmegfeleltetés, ellenőrzés, kötegépítés), és a jóváhagyás az ERP-ben marad a záráshoz szükséges többi jóváhagyás mellett. Ha az ERP-nek nincs importjóváhagyási lépése, az eszköz kimenete fájl lesz, amelyet egy második személy a köteg összesítőjével összevetve ellenőriz, majd maga importál.

Az automatikus könyvelést, fizetési fájlok készítését vagy szállítói bankadatok módosítását végző eszköz az IT-hoz tartozik, a következő szakasz feltételei szerint.

Sorolj fel minden helyet, ahol ez az alkalmazás [naplótételeket / számlákat / fizetéseket] hoz létre, módosít vagy könyvel a [ERP neve] rendszerben.

Módosítsd mindegyiket úgy, hogy az alkalmazás vázlattételt vagy előkészített importot írjon, amelyet a [ERP neve] rendszerben jóvá kell hagyni könyvelés előtt. Ha a [ERP neve] rendszerben nincs importjóváhagyási lépés, helyette készíts importfájlt, és ne könyvelj semmit.

Távolíts el minden kódutat, amely e jóváhagyás nélkül könyvel vagy fizetést engedélyez.

Minden köteghez készíts összesítőt a sorok számával, az összes Tartozik és az összes Követel összegével.

Sorolj fel mindent, ami még közvetlenül könyvel, hogy ellenőrizhessem.

Ellenőrizd, hogy működött: futtass egy köteget mintaadatokból. Semmi nem jelenhet meg könyveltként, amíg egy második felhasználó az ERP-ben jóvá nem hagyja. Ezután hasonlítsd össze a köteg összesítőjét az ERP-ben ugyanahhoz a köteghez megjelenő adatokkal: a sorok száma, az összes Tartozik és az összes Követel pontosan egyezzen. Egy sor eltérése sikertelen egyeztetés, nem kerekítési kérdés.

Pénzügyi adatok küldése olyan szolgáltatásoknak, amelyek nincsenek a te ellenőrzésed alatt

A teljes főkönyvi kivonatot AI API-nak küldő eltérésmagyarázó funkció minden sort harmadik félnek továbbít. Két kevésbé feltűnő út is kivisz adatokat: az oldalon lévő analitikai szkript, amely minden látogatást jelent a szolgáltatójának, és a teljes kéréstörzseket tároló hibakövető vagy napló, amelybe bérsorok, ügyfelek bankadatai és még nem publikált számok is bekerülhetnek.

A pénzügy által készített belső eszköznél tartsd távol a még nem publikált eredményeket és béradatokat a külső hívásoktól, kivéve, ha a szolgáltatást és a pontos adatáramlást a szervezet szállítói, biztonsági és megfelelőségi eljárása kifejezetten jóváhagyta. Minden másnál sorold fel a célokat, és hívásonként csak a szükséges mezőket küldd. Azt, hogy a külső szolgáltatás tárolja-e vagy tanításhoz használja-e a kapott adatokat, a szállítói szerződések aláírójának kell tisztáznia a szolgáltató saját feltételei alapján. Ha a csapat az eszköz használatának gyakoriságát szeretné ismerni, egy saját üzemeltetésű analitikai eszköz, például az Umami a saját kiszolgálón tartja az oldalmegtekintéseket.

Sorolj fel minden helyet, ahol ez az alkalmazás a [kiszolgálónkon] kívülre küld adatot, beleértve az AI API-kat, analitikai szkripteket, hibakövetést, e-mailt, webhookokat és naplófájlokat.

Minden célhoz sorold fel pontosan, mely mezőket kapja meg.

Jelezz mindent, ami [bérösszegeket / bankszámlaszámokat / még nem publikált eredményeket / ügyfélneveket] tartalmaz.

Minden jelzett elemnél mutasd meg, hogyan küldhető kevesebb mező vagy semmi, és csak az én megerősítésem után módosíts.

Ellenőrizd, hogy működött: indíts el minden funkciót egyszer felismerhető hamis számlaszámot és hamis bérösszeget tartalmazó mintaadatokkal. Keresd mindkét értéket a hibakövetőben és naplókban; nem lehet találat. Az AI API útvonalnál naplóztasd az alkalmazással a kimenő kérés törzsét a mintafuttatásban, keresd ugyanazt a két értéket a naplóban, és egyik sem lehet jelen, csak a jóváhagyott mezők. Utána kapcsold ki ezt a naplózást.

Számításmódosítás nyilvántartás és egyeztetés nélkül

Egy elhatároláskalkulátorban vagy bevételi waterfall-ellenőrzőben a kód maga a kontroll. Egy képlet módosításával a zárásba kerülő számok is módosulnak; verziókezelés nélkül senki sem tudja megmondani, ki mit és mikor változtatott.

Egy CPA-cég r/ClaudeAI-bejegyzése alatt, amely a Claude Code-dal készített belső eszközökről szólt, egy hozzászóló egyenesen megfogalmazta a határt: „a 'könyvelő + claude code' addig működik, amíg el nem éred az auditnyom-követelményeket. ez a tényleges felső határ.”

Bármilyen módosítás előtt rögzítsd a mai működést; a kimenetek rögzítése után a logika javítható anélkül, hogy az összegek észrevétlenül eltolódnának. Tartsd a kódot verziókezelésben, amely minden változást szerzővel és dátummal rögzít.

Írj teszteket, amelyek rögzített mintafájlon futtatják az eszközt, és a rögzített alapállapottal vetik össze az eredményeket, így a kódnak egyeztetésen kell átmennie bármely módosítás kiadása előtt. A rögzített teszt azt védi, amit rögzít, a hibákat is; ezért előbb egyeztesd az alapállapot összegeit az ERP adott időszaki összegeivel, és csak utána bízz bennük.

Követeld meg, hogy a számítási logika minden módosítását második személy ellenőrizze, és minden éles futást egyeztess az ERP saját összegeivel.

Ha még nincs, vedd ezt a projektet verziókezelés alá, és sorold fel a számítási logikát tartalmazó fájlokat.

Írj teszteket, amelyek a [mintafájlon] futtatják az alkalmazást, és rögzítik a mai kimeneteket: sorok száma és összegek [számla / gazdálkodó egység / időszak] szerint.

A rögzített kimenetek mentése előtt mutasd meg az összegeket, hogy egyeztethessem őket a [ERP neve] adataival a [időszak] időszakra.

Minden változtatás, amely ezen összegek valamelyikét módosítja, okozzon teszthibát.

A tesztek írása közben ne változtasd meg a számítási logikát.

Ellenőrizd, hogy működött: szándékosan módosíts egy számítást, például egy kerekítési szabályt, és ellenőrizd, hogy egy teszt elbukik. Vond vissza a változtatást, és győződj meg róla, hogy ismét minden teszt sikeres.

Alapértelmezésben magánhálózat, több felhasználóhoz vállalati bejelentkezés, a főkönyvhöz IT

Éles pénzügyi adat soha nem marad az AI-eszköz tárhelyén. Ha csak a pénzügyi csapatnak szeretnél biztonságosan üzembe helyezni AI-val készített alkalmazást, tedd az általad ellenőrzött, csak magánhálózaton elérhető kiszolgálóra. Adj hozzá vállalati bejelentkezést, amikor a csapaton kívülieknek szükségük van rá, és add át az IT-nak, ha az alábbi lista bármely eleme igaz.

A VPS bérelt virtuális kiszolgáló, amelynek operációs rendszerét és szoftverkészletét te ellenőrzöd. Egy magánhálózat (a Tailscale szóhasználatában tailnet) az engedélyezett eszközöket ehhez a kiszolgálóhoz kapcsolja. Az eszköz nyílt internettől való távoltartásához továbbra is tiltani kell az alkalmazás nyilvános bejövő elérését, például a kiszolgáló tűzfalával, és csak a VPN- vagy tailnet-interfészen szabad elérhetővé tenni. Az identitásszolgáltató tárolja a vállalati felhasználói fiókokat; a fordított proxy az alkalmazás előtti kapuőr, amely minden kérést előbb bejelentkezésen vezet át.

Az AI-eszköz saját tárhelye az első hibánál ismertetett okok miatt nincs a táblázatban. Egy vállalati üzembe helyezési platform, például a Northflank sem szerepel benne; ez nagyobb szervezetekhez illik, amelyek már költségvetést biztosítanak a platformszolgáltatóknak és az általuk megkövetelt ellenőrzéseknek. Ez több szerződéses terhet jelent, mint amennyit egy részleg néhány felhasználója által használt eszköz igényel.

Tapasztalatom szerint a két magánhálózati lehetőség közül a Tailscale gyorsabban bevezethető, de a koordinációs szolgáltatást maga a Tailscale üzemelteti. A teljesen saját üzemeltetésű megoldás a WireGuard.

Azért teszem alapértelmezetté a magánhálózatot, mert az internetről nem válaszoló eszköz kereséssel nem található meg, és bejelentkezési oldalán nem támadható, míg az AI-eszköz által írt bejelentkezési oldal csak olyan jó, mint a mögötte lévő AI-kód. Ha az alkalmazást a magánhálózaton túl is elérhetővé kell tenni, a vállalati bejelentkezés kezelt hitelesítési réteget tesz elé, ezért ez a második lépés.

Amikor a költségvetési felelősöknek hozzáférés kell, cseréld az eszköz saját bejelentkezését vállalati bejelentkezésre, más néven egyszeri bejelentkezésre (SSO): az emberek meglévő vállalati fiókjukat használják, így a fiók letiltása megakadályozza az új bejelentkezéseket. Állíts be munkamenet-visszavonást, háttércsatornás kijelentkezést vagy megfelelően rövid munkamenet-élettartamot, hogy a meglévő munkamenetek ne maradjanak fenn. Az utasítás OIDC-t használ, az Authentik és Keycloak által is támogatott szabványos bejelentkezési protokollt.

Cseréld az alkalmazás saját bejelentkezését vállalati bejelentkezésre a [Authentik / Keycloak / identitásszolgáltatónk] használatával, OIDC-n keresztül.

Olvasd ki minden felhasználó csoportját a bejelentkezésből.

Csak a [csoportnév] tagjainak engedélyezd [a béroldalakat], és érvényesítsd ezt a szabályt a kiszolgálón minden oldalra, exportra és API-végpontra, ne csak a menüben.

Utasíts el minden kérést, amelyhez nincs érvényes bejelentkezés.

Ellenőrizd, hogy működött: jelentkezz be egy nem csoporttag tesztfiókkal, kérd közvetlenül a korlátozott oldalt és annak export- vagy API-címét, és mindkettőnél elutasítást várj. Ezután tiltsd le a tesztfiókot az identitásszolgáltatónál, és ellenőrizd, hogy nem indíthat új munkamenetet. Ellenőrizd azt is, hogy egy meglévő munkamenetet visszavonnak, vagy a beállított időablakon belül lejár.

Egyes eszközök egyáltalán nem maradhatnak a csapatnál. Add át az eszközt az IT-nak vagy a fejlesztésnek, ha az alábbiak bármelyike igaz:

1. A főkönyvbe vagy más hiteles nyilvántartási rendszerbe könyvel anélkül, hogy valaki az ERP-ben jóváhagyná.
2. Fizetési fájlokat készít, fizetéseket engedélyez vagy szállítói bankadatokat módosít.
3. A kimenete SEC-nél regisztrált vállalat pénzügyi kimutatásait táplálja, ami az eszközt a pénzügyi beszámolás belső kontrolljai (ICFR) körébe vonhatja. A zárási használat előtt vesd fel a belső ellenőrzésnek; a SOX 404(b) szakasza alá tartozó kibocsátóknál a külső könyvvizsgáló is tesztelheti a kapcsolódó kontrollokat.
4. Fizetési kártyaadatokat tárol, dolgoz fel vagy továbbít.
5. Magánszemélyek hitelképességét pontozza.
6. A csapatból senki nem vállalja a javítások telepítését, a hozzáférés-ellenőrzéseket és a használatból kivonást.

A hatodik feltétel fontosabb, mint amilyennek látszik. Saját üzemeltetésnél tiéd a frissítések, biztonsági mentések és felügyelet felelőssége, és a senki által nem karbantartott pénzügyi eszköz biztonságosabb az IT-nál. Az IT lehet lassabb; ez az ára az e feltételekhez szükséges irányításnak.

Az 1. és 2. szinthez a kiszolgálónak, üzembe helyezési rétegnek, magánhálózatnak, a 2. szintnél pedig identitásszolgáltatónak is készen kell állnia, mielőtt bárki megnyitja az eszközt; egy mérnök nélküli pénzügyi csapatnak ezt magának kell felépítenie. A mi Linux VPS szolgáltatásunkon root hozzáférést kapsz. A Coolify és a WireGuard egy kattintással üzembe helyezhető; a Tailscale a hivatalos egyparancsos telepítővel telepíthető, a Authentik pedig a hivatalos Docker Compose-összeállításából fut. A csapat ideje így a fenti javításokra fordítható az üzembe helyezési rendszer nulláról építése helyett. Helyszíneink között szerepel Frankfurt és Amszterdam az EU-ban, London az Egyesült Királyságban, valamint több amerikai város; kiválaszthatod az alkalmazás elsődleges VPS-tárolójának régióját. A választás elfogadhatósága továbbra is a megfelelőségi csapat feladata.

Régiónként a megfelelőségi csapattal ellenőrizendő szabályok

Az alkalmazandó keretrendszerek attól függnek, hogy az eszköz mit érint, valamint hol van a vállalat és az adatokban szereplő emberek. Az EU-s munkavállalók fizetését tároló bértábla és egy amerikai tőzsdei vállalat pénzügyi kimutatásait tápláló bevételi ütemezés eltérő keretrendszerek alá tartozhat.

Ez a cikk semmilyen részében nem jogi tanácsadás. Az alábbi táblázat a megfelelőségi csapattal megvitatandó keretrendszereket sorolja fel, és nem dönti el, hogy bármelyik vonatkozik-e rád.

A SOX-sornál az AS 2201 a PCAOB szabványa arra a könyvvizsgálói tanúsításra, amelyre a Sarbanes-Oxley törvény 404(b) szakasza hivatkozik. A csalási kockázat kezelésekor a könyvvizsgáló által értékelt kontrollok között említi az időszak végi pénzügyi beszámolási folyamat naplótételeinek és helyesbítéseinek kontrolljait. E régiókon kívül a nemzeti adatvédelmi hatóság saját oldalán kezdd. A kiszolgáló helye meghatározza az elsődleges tároló helyét; nem mondja meg, hol van minden biztonsági mentés, napló vagy külső másolat, és önmagában nem teljesíti a fenti keretrendszerek egyikét sem.

Gyakran ismételt kérdések

Biztonságos a vibe coding pénzügyi eszközökhöz?

Az lehet, ha a bemutató után maradt hiányosságokat megszüntetik; a bizonyítékokat inkább üzembe helyezési, mint kódolási problémaként értelmezem. A pénzügyi eszköz kockázatosabb egy személyes projektnél, mert olvassa az ERP-t, és írhat a könyvekbe. Amint második jóváhagyó nélkül könyvel, fizetéseket kezel vagy kártyaadatokat érint, az IT-hoz tartozik.

Mi az árnyék-AI a pénzügyben?

Az árnyék-AI olyan AI-eszköz vagy AI-val készített alkalmazás, amelyet vállalati adatokon az IT tudta vagy jóváhagyása nélkül használnak, például egy ERP-hez kapcsolt előrejelző irányítópult, amelyet az IT soha nem látott. Az IBM 2025-ös Cost of a Data Breach Report jelentése szerint a sok árnyék-AI-t használó szervezetek adatsértési költsége átlagosan 670 000 USD-vel magasabb volt a keveset vagy semennyit nem használóknál, az IBM bejelentése szerint.

Mit mutassunk be a belső ellenőrzésnek vagy a külső könyvvizsgálónak?

A zárási használat előtt vigyél négy dolgot: hol fut és ki érheti el az eszközt, a változási előzményeket a rögzített kimenetek tesztjeivel, az ERP-ben történő könyvelés jóváhagyási módját, és a kötegenkénti ERP-összegekkel egyező egyeztetési bizonyítékokat. Hogy a könyvvizsgáló mit követel meg, azt ő dönti el; ezek konkrét értékelhető anyagot adnak neki.

Ki felel az AI-val készített pénzügyi eszközért, miután a készítője továbblép?

Indítás előtt nevezz meg egy pénzügyi felelőst és egy műszaki kapcsolattartót. Az eszközt a készítő saját fiókja helyett szolgáltatási hitelesítő adattal futtasd, és a hozzáférést vállalati bejelentkezésen vezesd át, hogy a távozó vállalati fiókjának letiltása megakadályozza az új bejelentkezéseket, a meglévő munkamenetek pedig a szabályzat szerint visszavonásra kerüljenek vagy lejárjanak. A használatból kivonás a hitelesítő adatok letiltását, a megőrzési szabályzat által előírtak megtartását, a többi törlését és az eszköz leállítását jelenti.