Biztonság és bizalom

1. Egyoldalas összefoglaló

Az őszinte jelenlegi helyzetünk 2026. július 8-i állapot szerint: a Nose for Horse (a továbbiakban: „Nose”) korai fázisban lévő termék, amelyet egyetlen személy üzemeltet. Ma NEM rendelkezünk SOC 2 vagy ISO 27001 tanúsítvánnyal, és külső penetrációs teszten sem estünk még át. Ez az oldal azt írja le, hogy mit teszünk, milyen adatokat tárolunk, és mi az, amivel még nem rendelkezünk. Inkább nyíltan megmondjuk, hol tartunk, mint hogy többet állítsunk a valóságnál.

• Kik vagyunk. A Nose lovasiskolák működtetésére szolgáló szoftver — a lovaglóórák órarendbe szervezése, a jelenlét és a lovasok fizetési módjának nyomon követése, a bérletek és ajándékutalványok kezelése, a lovasoktatók keresetének kiszámítása, valamint betekintés biztosítása a lovarda ügyfeleinek a saját foglalásaikba. Üzemeltetője a DF Daniel Fojcik, lengyel egyéni vállalkozás (NIP 6472592229 / REGON 387798601, Marklowice), amely Nose for Horse néven működik.
• A két szerepünk. A saját fiók-, analitikai és biztonsági adataink tekintetében adatkezelők vagyunk, az egyes lovardák által rögzített lovas- és ügyféladatok tekintetében pedig az adott lovarda utasításai szerint eljáró adatfeldolgozók. Az adatfeldolgozói jogviszonyt az adatfeldolgozási szerződésünk (DPA) szabályozza. Lásd alább a „Megfelelőségi keretek” részt.
• Milyen adatokat tárolunk. A fiókhoz tartozó e-mail-cím és a profil választható neve/telefonszáma; a meghívók e-mail-címei; azok az üzemeltetési nyilvántartások, amelyeket egy lovarda a lovasairól rögzít (nevek, elérhetőségek, órákon való részvétel, bérletek és utalványok, fizetésnyilvántartási címkék, szabad szöveges megjegyzések); a bcrypt algoritmussal hasított órarend-PIN-kódok; a SHA-256 algoritmussal hasított meghívótokenek. Bankkártya- és bankadatokat, valamint egészségügyi adatokat nem tárolunk. A teljes leltár alább, „Az általunk tárolt adatok” részben található.
• Mi védi ezeket. Mindenütt TLS, HSTS-szel és preload beállítással; a tárolt adatok titkosítása (AES-256); az adatbázisban kikényszerített, az egyes lovardákat elkülönítő sorszintű biztonság; kiszolgálóoldali munkamenet-ellenőrzés; megerősített újrahitelesítés a visszafordíthatatlan és adminisztrátori műveletekhez; szigorú Content Security Policy; kérésszám-korlátozás és botvédelem; valamint csak bővíthető auditnapló. A teljes lista alább, a „Technikai intézkedések” részben.
• Hol fut. Egynél több adatrégióban, és a növekedésünkkel újabb régiókat veszünk fel. Az USA-régióban lévő lovardák ügyféladatait az Egyesült Államokban tároljuk. A szolgáltatás üzemeltetése, adminisztrációja és támogatása az Európai Unióból történik. Az EU-régiónkban lévő lovardákat az EGT-ből szolgáljuk ki. Néhány szolgáltatást a két régió közösen használ, és ezek az EGT-ben futnak — tranzakciós e-mailek, hibafigyelés, hozzájáruláshoz kötött analitika —, néhány komponens pedig globálisan fut. Az egyes szolgáltatók régióit és adattovábbítási mechanizmusait — adatrégiónként külön — alább, az „Infrastruktúra — ki mit üzemeltet, és hol” részben, valamint a További adatfeldolgozók oldalon találja.
• Amivel még nem rendelkezünk. Nincs SOC 2, ISO 27001, külső penetrációs teszt vagy hibafelderítési jutalomprogram (bug bounty). Ha az Ön beszerzési folyamata ma SOC 2-t követel meg, akkor még nem mi vagyunk a megfelelő szolgáltató.
• Hogyan érhet el minket biztonsági ügyben. Írjon a support@nose.horse címre, a tárgy mezőben a `Security` szóval. Lásd alább az „Incidenskezelés (adatvédelmi incidens bejelentése 72 órán belül)” és a „Felelős hibabejelentés” részt.

2. Az általunk tárolt adatok

A Szolgáltatás működtetéséhez szükséges minimumot gyűjtjük. Az alábbi kategóriák azok a személyes adatok, amelyekkel a Nose kapcsolatba kerül.

Ahol egy sor az Ön lovardájának régióját említi, ott az EU-régióról vagy az USA-régióról van szó — ezt a lovarda létrehozásakor rögzítjük, és alább, az „Infrastruktúra — ki mit üzemeltet, és hol” részben írjuk le részletesen.

Amit nem tárolunk

• Semmilyen bankkártya- vagy bankadat. A Nose soha nem szereplője egy fizetésnek, és soha nem kezel kártyaadatot. Az offline módok („készpénz”, „bérlet”, „utalvány”, „átutalás”) a lovarda által rögzített nyilvántartási címkék — nem a Nose által lebonyolított tranzakciók. A lovarda előfizetésének számlázásánál (Stripe a lengyel lovardáknál, Dodo Payments mint Merchant of Record a Lengyelországon kívüli lovardáknál), valamint a lovasok online fizetéseinél ott, ahol ezt a lovarda engedélyezi (Stripe, a lovarda saját Stripe-fiókjába történő elszámolással), a kártyaadatokat kizárólag a fizetési szolgáltató saját fizetőoldala kezeli, és azok soha nem jutnak el hozzánk — így a PCI DSS hatályán kívül maradunk (lásd alább a „Megfelelőségi keretek” részt).
• Semmilyen személyazonosító okmány vagy cím. Nem gyűjtünk lakcímet, okmányazonosítót vagy állami azonosítót.
• Semmilyen különleges kategóriájú (egészségügyi) adat. Nem áll szándékunkban a GDPR 9. cikke szerinti adatokat gyűjteni, és a termék nem is ezek tárolására készült. A lovardák (az adatfeldolgozási szerződésben) azt az utasítást kapják, hogy ne rögzítsenek különleges kategóriájú adatot a szabad szöveges mezőkben. A lóra vonatkozó megjegyzések állatra, nem személyre vonatkoznak, és kívül esnek a GDPR hatályán.
• Semmilyen hirdetési profil, retargeting-azonosító vagy webhelyek közötti követés. Nincs Meta-, LinkedIn-, X- vagy TikTok-pixel; nincs böngészőujjlenyomat-készítés.
• Adatot nem adunk el, nem adunk bérbe és nem adunk kölcsön harmadik feleknek.
• Nem tanítunk MI-/gépi tanulási modelleket az Ön adatain. A Nose rendszeréből származó személyes adatokon semmilyen mesterséges intelligencia vagy gépi tanulási modellt nem tanítunk, nem finomhangolunk és nem értékelünk ki. A `pgvector` bővítmény a Postgres-adatbázisunkban jövőbeli belső keresési felhasználásokhoz engedélyezve van, de ma nincs feltöltve semmilyen, személyes adatból származó vektorreprezentációval.

3. Infrastruktúra — ki mit üzemeltet, és hol

A Nose egy Vercelen üzemeltetett Next.js alkalmazás, amely Supabase Postgres adatbázisra épül, mellette néhány szakosodott szolgáltatóval („további adatfeldolgozók”), amelyek mindegyike csak egy szűk szeletet lát el. Egyiküknek sincs végponttól végpontig terjedő hozzáférése mindenhez. A Nose két adatrégiót üzemeltet: egy EU-régiót és egy USA-régiót. Az USA-régióban lévő lovardák ügyféladatait az Egyesült Államokban tároljuk. A szolgáltatás üzemeltetése, adminisztrációja és támogatása az Európai Unióból történik. Egy lovarda üzemeltetési adatai kizárólag a saját régiójának adatbázisában találhatók — nincs replikáció a régiók között, és nincs olyan alkalmazásbeli útvonal sem, amely a régiók között olvasna. Három szolgáltatást a két régió közösen használ, és ezek az EGT-ben maradnak — a tranzakciós e-mailek, a hibafigyelés és a hozzájáruláshoz kötött termékanalitika. Az alábbi táblázat adatrégiónként külön adja meg az egyes szolgáltatók régióját; a kanonikus lista — az adatkategóriákkal és az adattovábbítási mechanizmusokkal — a További adatfeldolgozók oldal.

Ennek a táblázatnak a hiteles, mindig naprakész változatát — szolgáltatónkénti személyesadat-kategóriákkal és adattovábbítási garanciákkal — a További adatfeldolgozók oldal tartja karban; az Adatkezelési tájékoztató és az adatfeldolgozási szerződés ugyanerre a forrásra hivatkozik ahelyett, hogy egymástól eltérő másolatokat tartana fenn.

4. Technikai intézkedések

Ezek azok a védelmi intézkedések, amelyek ma ténylegesen működnek. Egyben ez az a tartalom, amely az adatfeldolgozási szerződés → „Titoktartás, biztonság és további adatfeldolgozók” pontja mögött áll: az a pont a technikai és szervezési intézkedéseink tekintetében ide utal.

Hálózat és átvitel

• TLS minden forgalomra, amelyet a Vercel és a Supabase kényszerít ki. A HSTS beállítása: `max-age=63072000; includeSubDomains; preload`.
• Nincs vegyes tartalom — a Content Security Policy elutasítja a `http://` protokollú erőforrásokat.

Bérlők elkülönítése és jogosultságkezelés

• Lovardánként hatályos sorszintű biztonság (RLS) minden üzemeltetési táblán, magában az adatbázisban kikényszerítve — az egyik lovarda adatait a másik akkor sem tudja kiolvasni, ha az alkalmazás kódjában hiba lenne. Ez az elsődleges védelem a bérlők között.
• Alkalmazásszintű szerepkör-ellenőrzések (bejelentkezett / lovardára szűkített / lovasoktató vagy adminisztrátor / szuperadminisztrátor) az RLS fölött, több rétegű védelemként, soha nem egyedüli védvonalként.
• Útvonalszintű ellenőrzések aktív munkamenetet követelnek meg a védett útvonalakhoz, az adminisztrátori felülethez pedig szuperadminisztrátori jogosultságot.

Hitelesítés

• Jelszó nélküli bejelentkezés — e-mailes belépési link (a Supabase Auth kezeli) vagy választható Google-bejelentkezés (OAuth). Jelszót nem tárolunk.
• Kiszolgálóoldali munkamenet-ellenőrzés minden védett kérésnél — önmagában a bejelentkezési sütinek soha nem hiszünk.
• Megerősített újrahitelesítés a visszafordíthatatlan és adminisztratív műveletekhez — rövid élettartamú, külön aláírt megerősítő süti szükséges az olyan műveletekhez, mint a fiók törlése, az utolsó adminisztrátor szerepkörének módosítása, a tömeges inaktiválás, a lovarda archiválása és minden szuperadminisztrátori írási művelet; ha a megerősítés hiányzik vagy lejárt, a művelet biztonságosan elutasításra kerül.
• A platform adminisztrátori felülete 404-es hibát ad vissza, ha nincs beállítva szuperadminisztrátor, így még a létezése sem derül ki.

Titkok és hozzáférési adatok kezelése

• Az órarend-PIN-kódokat bcrypt hash formájában tároljuk; a meghívótokeneket SHA-256 hash formájában — ezek egyszer használhatók, időben korlátozottak (7 napos lejárat) és e-mail-címhez kötöttek; a nyers tokeneket soha nem őrizzük meg.
• Az adatbázis szolgáltatói kulcsa kizárólag kiszolgálóoldali — soha nem kerül bele a kliensoldali JavaScriptbe; egy fordításkori ellenőrző megbuktatja a fordítást, ha egy érzékeny változó előtagja hibás.

Be- és kimenetek kezelése

• Sémaellenőrzés minden kiszolgálóoldali bemeneti határon — a kliensoldali ellenőrzést kizárólag a felhasználói élményt szolgáló elemnek tekintjük; a bizalmi határ a kiszolgáló.
• Szigorú Content Security Policy kérésenkénti nonce-értékkel, valamint zárt biztonsági fejléckészlet (`X-Content-Type-Options`, `X-Frame-Options` / `frame-ancestors`, `Referrer-Policy`, a forrásközi izolációt biztosító fejlécek és egy korlátozó `Permissions-Policy`).
• Automatikus kimeneti escape-elés; a felhasználók által írt tartalom ebben a fázisban egyszerű szöveg.

Visszaélés- és botvédelem

• Kérésszám-korlátozás a bejelentkezésnél, a regisztrációnál, a belépési linknél, a meghívó elfogadásánál, az exportnál és a törlésnél, valamint további érzékeny végpontokon (e-mail-cím, IP-cím, felhasználó vagy lovarda szerint, a művelettől függően; minden szabály tervezetten vagy hiba esetén átengedő, vagy hiba esetén blokkoló).
• Cloudflare Turnstile botvédelem a bejelentkezési űrlapon, a regisztrációs űrlapon, a belépési link kérésénél, a meghívóelfogadó oldalon és a nyilvános órarend PIN-kódjának megadásánál.

Tárolt adatok és auditnapló

• A tárolt adatok titkosítása a Supabase révén (AES-256).
• Csak bővíthető auditnapló rögzíti a biztonsági szempontból lényeges eseményeket (hitelesítés, szerepkör- és tagsági változások, pénzügyi események, exportok, törlések). Mindig íródik, és elkülönül az üzemeltetési telemetriától.
• Hibafigyelés személyesadat-tisztítással — mielőtt bármely hiba a Sentrybe kerülne, egy egyedi tisztító eltávolítja az e-mail-címeket, a telefonszámokat, az üzenetszövegeket, a megjegyzéseket és minden olyan mezőt, amely tokennek tűnik. Ami marad, az a technikai környezet, valamint egy álnevesített felhasználói UUID, a lovarda azonosítója, a nyelv és a hibát okozó művelet neve.

Mentések és helyreállítás

• A Supabase automatikus napi mentéseket készít (a jelenlegi csomagban 7 napos megőrzéssel; a Szolgáltatás érésével hosszabb megőrzés tervezett). A Vercel megőrzi a korábbi telepítéseket, így egy hibás kiadás szinte azonnal visszaállítható.

5. Szervezési intézkedések

• Egyszemélyes üzemeltetés. A Nose-t egyetlen személy (Daniel Fojcik) működteti. Jelenleg nincs olyan alkalmazott, aki hozzáférne az éles rendszerhez. Ha ez megváltozik — például ha éles hozzáféréssel rendelkező alvállalkozó lép be —, ezt az oldalt frissítjük, és az aktív lovardákat értesítjük.
• Az éles adatok kezelt infrastruktúrán maradnak. Az éles adatbázis mentéseit nem tároljuk helyi gépeken; a helyi fejlesztés külön adatbázist használ szintetikus adatokkal.
• A legkisebb jogosultság elve a szolgáltatásfiókoknál. Az adatbázis szolgáltatói kulcsa kizárólag kiszolgálóoldali használatra korlátozott; a böngészőből történő adatbázis-hozzáférés korlátozott kulcsot használ, a sorszintű biztonság mögött.
• A titkok kezelése. A titkok a tárhelyszolgáltató környezeti konfigurációjában és egy verziókövetésből kizárt helyi fájlban élnek — soha nem kerülnek be a kódtárba. Az éles titkokat nem másoljuk helyi gépekre.
• Szolgáltatóoldali hozzáférés-naplózás. A szolgáltatóinknál végzett adminisztratív műveleteket maguk a szolgáltatók naplózzák; ezeket eseti alapon tekintjük át.
• Titoktartás. A személyzetet (jelenleg magát a vállalkozót) titoktartás köti a Szolgáltatáson keresztül kezelt személyes adatok tekintetében, ahogyan azt az adatfeldolgozási szerződés is rögzíti.
• Változtatási fegyelem. A kódváltoztatások telepítés előtt szigorú típus-, lint- és automatizált teszteken alapuló kapun mennek át, az adatbázis-migrációkat pedig az éles környezet előtt előkészítő (staging) környezetben alkalmazzuk.

6. Incidenskezelés (adatvédelmi incidens bejelentése 72 órán belül)

Figyelés. A hibák a Sentrybe futnak be (a fent, a „Technikai intézkedések” részben leírt személyesadat-tisztítással); a kérésszintű diagnosztika a tárhely naplóiban érhető el; a rendelkezésre állás figyelése és a hibaarány-riasztás a megerősítési alapcsomag része. A csak bővíthető auditnapló tartós nyilvántartást ad a biztonsági szempontból lényeges eseményekről a vizsgálatokhoz.

Az adatvédelmi incidens bejelentésére vonatkozó vállalásunk. Ha olyan adatvédelmi incidens következik be, amely valószínűsíthetően kockázattal jár az érintettek jogaira és szabadságaira nézve, akkor:

• Bejelentjük az illetékes felügyeleti hatóságnak — a lengyel adatvédelmi hatóság (UODO) elnökének — indokolatlan késedelem nélkül, és lehetőség szerint az incidensről való tudomásszerzéstől számított 72 órán belül (GDPR 33. cikk).
• *Ha az incidens valószínűsíthetően magas* kockázattal jár az érintettekre nézve, őket is tájékoztatjuk indokolatlan késedelem nélkül, ismertetve az incidens jellegét, az érintett adatkategóriákat, a valószínű következményeket és a megtett intézkedéseket (GDPR 34. cikk**).
• Ha egy lovarda adatfeldolgozójaként járunk el, indokolatlan késedelem nélkül értesítjük az adott lovardát (az adatkezelőt), hogy az teljesíthesse a lovasaival szembeni saját, 33. és 34. cikk szerinti kötelezettségeit.

Ez összhangban van az Adatkezelési tájékoztatóval és az adatfeldolgozási szerződéssel. Azt rögzíti, hogyan kívánunk eleget tenni egy olyan kötelezettségnek, amelyet a GDPR már előír — nem a GDPR-on túlmutató további szerződéses ígéret. A formálisan dokumentált incidenskezelési kézikönyv tervben van; addig az egyfős csapat eseti alapon, a fenti határidőkön belül reagál.

Kapcsolat. Nem sürgős esetben: support@nose.horse. Biztonsági (sürgős) ügyben: írjon a support@nose.horse címre, a tárgy mezőben a `Security` szóval.

7. Megfelelőségi keretek

GDPR (az (EU) 2016/679 rendelet). A Nose kettős szerepben működik: adatkezelő azoknál az adatoknál, amelyek kezelésének céljait és eszközeit maga határozza meg (a marketingoldal látogatói, a lovardák adminisztrátorainak és lovasoktatóinak fiók- és kapcsolattartási adatai, a hozzájáruláshoz kötött termékanalitika, valamint a biztonsági és visszaélés-megelőzési adatok), és adatfeldolgozó a lovarda által rögzített lovas- és ügyféladatoknál — ott a lovarda az adatkezelő, a Nose pedig a lovarda dokumentált utasításai szerint, az adatfeldolgozási szerződés alapján kezeli az adatokat (GDPR 28. cikk). A további adatfeldolgozók a 28. cikk szerinti szerződések alapján járnak el (adatfeldolgozási szerződés + általános adatvédelmi kikötések/DPF, az Egyesült Királyságra vonatkozó kiegészítés vagy azzal egyenértékű garancia ott, ahol az adattovábbítás régióhatárt lép át) — lásd a További adatfeldolgozók oldalt.

Gyermekek adatai. A lovasiskolák rendszeresen tanítanak gyermekeket, ezért a Nose tudatosan kezel kiskorúak adatait egy lovarda nevében (például amikor egy gyermeket óra résztvevőjeként rögzítenek, gyakran a szülő, aki a lovarda ügyfele). A jogalapért, valamint a rá irányadó jog szerint szükséges szülői hozzájárulásért vagy engedélyért a lovarda felel (az EU-ban és az Egyesült Királyságban a GDPR 8. cikke; az Egyesült Államokban a COPPA és az egyes szövetségi államok joga); a Nose minimalizálja a gyermekről tárolt adatok körét, és nem célozza meg a gyermekeket, illetve nem szólítja meg őket közvetlenül marketinggel. Lásd az Adatkezelési tájékoztató → „Gyermekek adatainak védelme” részt.

Az érintetti jogokat támogatjuk, ideértve az önkiszolgáló hozzáférést és adathordozhatóságot a /account/export címen elérhető JSON-exporttal, valamint a törlést a /account/delete címen (30 napos, visszafordítható türelmi idő és megerősített újrahitelesítés mellett; törléskor a közvetlen azonosítókat távolítjuk el a végleges törlés helyett — ez a GDPR 4. cikk 5. pontja szerinti álnevesítés, nem a (26) preambulumbekezdés szerinti teljes anonimizálás; a mezőszintű részleteket lásd az Adatkezelési tájékoztató → „Meddig őrizzük meg az adatokat” részének megőrzési táblázatában). A lovasok adatainál az adatkezelő a lovarda, ezért a lovas a jogait a saját lovardájával szemben gyakorolja, a Nose pedig adatfeldolgozóként nyújt ehhez segítséget.

PCI DSS — a Nose-ra nem alkalmazandó. Kártyaadatokat nem kezelünk, nem tárolunk és nem továbbítunk. A lovarda előfizetésének számlázásánál a kártyaadatok útja teljes egészében a fizetési szolgáltató saját fizetőoldalán vezet — a lengyel lovardáknál a Stripe (fizetési szolgáltató), ahol a kereskedő a Nose, a Lengyelországon kívüli lovardáknál pedig a Dodo Payments mint Merchant of Record. A lovasok online fizetéseinél ott, ahol azokat a lovarda engedélyezi, a kártya-, pénztárca- vagy (Lengyelországban) BLIK-adatokat teljes egészében a Stripe viszi (a Stripe Connecten keresztül), és azok a lovarda saját Stripe-fiókjába kerülnek elszámolásra — a kereskedő a lovarda, a Stripe pedig a PCI-nek megfelelő fizetési szolgáltató, míg a Nose csupán utasításokat közvetít, és kártyaadatot soha nem kap. A Nose egyik esetben sem kap kártyaadatot, és a PCI hatályán kívül marad.

Az EU mesterségesintelligencia-rendelete — nem alkalmazandó. A Nose lovasiskolák számára készült üzemeltetési eszköz; nem tanít, nem fejleszt és nem helyez üzembe MI-modelleket, és egyetlen összetevője sem használ gépi tanulást vagy generatív mesterséges intelligenciát személyes adatok kezelésére. A `pgvector` Postgres-bővítmény esetleges jövőbeli belső keresési felhasználásokhoz engedélyezve van, de ma nincs feltöltve személyes adatból származó vektorreprezentációkkal; ha ez megváltozik, a funkció megjelenése előtt közzétesszük az EU mesterségesintelligencia-rendeletével kapcsolatos álláspontunkat és a „személyes adatokon nem tanítunk” vállalásunkat.

ePrivacy / sütik. A választható analitika (PostHog) csak hozzájárulás esetén töltődik be; a feltétlenül szükséges sütik az elektronikus hírközlési adatvédelmi irányelv 5. cikkének (3) bekezdése alapján mentesülnek. Lásd a Sütikezelési tájékoztatót.

8. Felelős hibabejelentés

Ha úgy véli, hogy biztonsági sérülékenységet talált a Nose rendszerében:

• Írjon a [support@nose.horse](mailto:support@nose.horse) címre, a tárgy mezőben a `Security` szóval. (Külön `security@` cím és PGP-kulcs tervben van.)
• Adjon meg annyi részletet, amennyi a hiba reprodukálásához szükséges.
• Hagyjon ésszerű időt a vizsgálatra és a javításra, mielőtt bármit nyilvánosságra hozna.

Mire számíthat tőlünk:

• Visszaigazolás és első értékelés, amint az ésszerűen lehetséges. A Nose egyetlen személy által üzemeltetett szolgáltatás, és nem tud aznapi választ garantálni; egy hiteles bejelentést azonban nem hagyunk figyelmen kívül.
• Tájékoztatás az állapotról ésszerű időközönként, amíg a hiba besorolása vagy javítása folyik.
• Megemlítés a javítás utáni nyilvánosságra hozatalban, ha Ön ezt szeretné (választható).

Amit még nem tudunk kínálni: ebben a fázisban nem fizetünk pénzbeli jutalmat a talált hibákért. Ha és amikor jutalomprogram indul, ezt egyértelműen közöljük.

Hatókör és mentesség. A jóhiszemű biztonsági kutatást, amely követi ezt a szabályzatot, az Ön saját fiókjain belül marad, nem rontja a Szolgáltatás működését mások számára, és nem fér hozzá az Önén kívüli adatokhoz, nem tekintjük az Elfogadható használati szabályzatunk vagy az Általános Szerződési Feltételeink megsértésének. Ne kísérelje meg más lovarda vagy más lovas adataihoz való hozzáférést, és ne futtasson automatizált adatgyűjtést vagy szolgáltatásmegtagadási tesztet a Szolgáltatás ellen.

9. Változásnapló