Arkaluonteisen arvon korvaava tunniste ja käyttöoikeuden välittävä tunniste palvelevat eri tarkoituksia. Käyttöala ja palvelimen oikeustarkistukset ovat silti ratkaisevia.
Korvaava arvo voi edelleen aiheuttaa riskejä
Tokenisointi korvaa arkaluonteisen arvon. Menetelmä voi olla palautuva tai palautumaton ja käyttää tai olla käyttämättä vastaavuusvarastoa. Tunniste voi edelleen mahdollistaa yhdistämisen tai sallittuja toimintoja; sen varastaminen ei välttämättä ole vaaratonta. Pseudonymisointi ei ole anonymisointia: GDPR:n ehtojen täyttyessä tiedot ovat yhä henkilötietoja.
Suojaa kanava ja tarkista jokainen toiminto
TLS suojaa liikennettä päätepisteidensä välillä, mutta ei korjaa puutteellista valtuutusta tai murrettua palvelinta. Allekirjoitettu JWT ei välttämättä ole salattu; sisältö voi olla luettavissa. Tarkista allekirjoitus, myöntäjä, vastaanottaja ja voimassaolo protokollan mukaisesti sekä kohdekohtaiset oikeudet. Käytä OAuthissa RFC 9700:aa ja määritä elinkaari, peruminen ja uudelleenkäytön torjunta arkkitehtuurin mukaan.
Kolme mekanismia ja niiden rajat
| Mekanismi | Tarkoitus | Tarkistettava raja |
|---|---|---|
| Tietojen tokenisointi | Korvata arkaluonteinen arvo. | Vastaavuus, uudelleentunnistus ja tunnisteen käyttötavat. |
| Salaus | Suojata luottamuksellisuus avaimilla. | Avainten hallinta ja tiedot salauksen purkamisen jälkeen. |
| Pääsytunniste | Esittää käyttöoikeus palvelulle. | Varastettua bearer-tunnistetta voidaan käyttää uudelleen; tarkista oikeudet palvelimella. |
Lähteet ja rajaus
- PCI SSC · Tokenization Product Security Guidelines · 2015 · pp. 6–8
- IETF · RFC 7519 · JSON Web Token · 2015
- IETF · RFC 9700 · OAuth 2.0 Security BCP · 2025
- EUR-Lex · GDPR / RGPD · Art. 4(5), recital 26
Toimituksellinen tarkistus: 31. lokakuuta 2026.
Älä sekoita suojattuja tietoja valtuutettuihin toimintoihin.
Salaus ja tokenisointi vähentävät jonkin verran tietoon liittyvää altistumista, mutta eivät päätä, voiko API-kutsu lukea objektin tai käynnistää toiminnon. OWASP listaa objektitason ja toimintotason valtuutuksen merkittävien API-riskien joukossa.
- Tarkista jokaisen pyydetyn objektin ja toiminnon käyttöoikeudet, jopa todennetun yhdyskäytävän takana.
- Testaa tilien ja roolien välisiä pyyntöjä demonstraatiotiedoilla.
- Säilytä tutkintavalmiita tietueita ilman salaisuuksien tai arkaluonteisten arvojen kirjaamista selkokielellä.
Ensisijainen lähde: OWASP API Security Top 10 — 2023. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Passkeyt: verkkotunnuksen ja RP ID:n vaihto
Erota tili, verkkoalkuperä ja RP ID, jotta tunnistetietoja ei siirretä hiljaisesti uuteen rajaukseen.
- Kirjaa vanhat ja uudet alkuperät, RP ID:t ja niihin liittyvät tilit. Sama tilinimi ei tee passkeysta kelvollista toiselle RP ID:lle. Tarkista WebAuthnin sallimat yhdistelmät ja siirtymän aikana toimivat pääsypolut.
- Tarkista valtuutetussa testiympäristössä haaste, alkuperä, RP ID ja tilisidonta sopivalla kirjastolla. Testaa odottamaton alkuperä ja toistettu haaste. RP ID:n vaihto vaatii uuden tunnistetun rekisteröinnin; rivin kopiointi ei siirrä avainta.
- Testaa käyttäjä, jolla on vain vanha tunniste, palautuminen ja avoimet istunnot. Määritä polkujen avaus ja poisto testatulla paluulla. Rekisteröinti uudessa tunnuksessa ei osoita kaikkien vanhojen istuntojen peruuttamista.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}Odotettu päätös
Kuvitteellinen esimerkki: tili säilyy, mutta old.example vaihtuu new.exampleksi eri RP ID:llä. Vanhaa tunnistetta ei voi hiljaisesti siirtää; uusi rekisteröinti seuraa suunniteltua tunnistettua polkua.
Voiko tietokantamuutos vaihtaa passkeyn RP ID:n?
Ei. RP ID kuuluu tunnisteen varmennettuun rajaukseen. Valmistele kelvollinen uusi rekisteröinti ja tunnistettu tilikytkentä.
Ensisijainen lähde: W3C — Web Authentication Level 2. Aiheeseen liittyvä menetelmä: lue käytännön opas.
TLS-uusiminen: varmista todella tarjottu varmenne
Seuraa uusimista päätepisteisiin ja asiakkaille ennen muutoksen valmistumisen ilmoittamista.
- Luettele nimet, CDN:t, kuormantasaajat, välityspalvelimet ja sisäiset varmennetta tarjoavat yhteydet. Kirjaa tarjottu varmenne, ketju, päättyminen ja omistaja. Myöntäminen ei todista asennusta joka solmuun. Suojaa yksityiset avaimet äläkä kirjaa niitä luetteloon.
- Testaa automaatio tarjoajan testiympäristössä, jos sellainen on. Tarkista haasteet, SAN-nimet, suojattu tallennus ja komponenttien uudelleenlataus. Vältä myöntämistä joka käynnistyksessä, jos avainpolitiikan mukainen käyttökelpoinen varmenne on olemassa.
- Tarkista nimet, päivät ja luottamusketju tuetuilla asiakkailla olennaisilla reiteillä. Pidä TLS-tarkistus käytössä. Valvo tarjotun varmenteen päättymistä, ei vain ajastimen tilaa. Paluu vaatii voimassa olevan varmenteen ja vaarantumattoman avaimen; muuten korjaa tai eristä päätepiste.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"issuance_succeeded": true,
"proxy_count": 2,
"proxies_serving_expected_certificate": 1,
"other_proxy_certificate_expired": true,
"tls_verification_enabled": true,
"expected": "change_incomplete_fix_and_verify_client_paths"
}Odotettu päätös
Kuvitteellinen esimerkki: uusiminen onnistuu, mutta toinen kahdesta välityspalvelimesta tarjoaa vanhentunutta varmennetta. Muutos on kesken; korjaa piste ja tarkista asiakasreitit poistamatta TLS-tarkistusta.
Ensisijainen lähde: Let’s Encrypt — Integration Guide. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Lähteet: tiedot, käyttö ja rajat
Aineisto tarkistettu .
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
| Lähde ja tarkoitus | Tarkistettu tieto tai vertailukohta | Käyttö käytännössä | Huomioitava rajoitus |
|---|---|---|---|
| MITRE · Common Weakness Enumeration Name classes of software and hardware weakness. |
A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident. | Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests. | A keyword in a report alone does not establish the correct CWE classification. |
| OASIS · TAXII 2.1 Exchange threat intelligence through an application protocol. |
TAXII 2.1 is an OASIS Standard dated 10 June 2021. It includes service discovery and access to collections. | Test authentication, collection permissions, pagination and recovery after interruption. Record which objects were actually received and processed. | TAXII transports data; it replaces neither the content model nor assessment of reliability. |
Tutki CISAn KEV-luetteloa
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
One identifier can span several technical layers
An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.
- Connect the CVE, component supplier and final-product supplier.
- Check version, configuration and execution path in the authorised environment.
- Do not infer remediation from an empty search result.
Tutki luetteloa ja menetelmää →
CISA KEV · 2026.11.06 · Documentary review : 2026-11-07
Tallennusvälineet: puhdistus ja näyttö
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
Encryption and erasure require different evidence
Encryption protects access while keys and implementation retain their properties. Cryptographic erase requires suitable encrypted scope and sanitization of relevant keys; it does not follow from API-token removal.
- Map data-encryption, wrapping and derivation keys and external copies.
- Check whether target sensitive data previously existed in plaintext.
- Record technical outcome, limits and validation without retaining secrets in the evidence.
Read the methods, evidence points and annotated situations →
NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23