Palveluverkko sotilaalliseen zero-trust-arkkitehtuuriin: mTLS, politiikan valvonta ja havainnoitavuus puolustusklustereissa

Kubernetes-klusteri, joka ajaa puolustuksen mikropalveluja, ei ole luonnostaan zero-trust. Oletusarvoinen pod-verkkomalli sallii minkä tahansa podin aloittaa TCP-yhteyden mihin tahansa muuhun podiin samassa klusteriverkossa, mikä tarkoittaa, että yksi vaarantunut säiliö voi saavuttaa todennuspalvelut, tietosäilöt ja komentokäyttöliittymät, joihin sillä ei ole laillista syytä päästä. Palveluverkko ratkaisee tämän ongelman ei uudelleenkonfiguroimalla verkon ACL-listoja — jotka ovat epäluotettavia dynaamisissa säiliöympäristöissä — vaan lisäämällä kryptografisen identiteetin ja käytäntöjen valvonnan suoraan jokaisen palveluiden välisen kutsun datapolulle. Tässä artikkelissa tarkastellaan, mitä se tarkoittaa käytännössä puolustusklustereille: kuinka SPIFFE/SPIRE integroituu sotilaallisten verkkojen zero-trust-arkkitehtuuriin, kuinka aiepohjainen käytäntö korvaa perimeteriin perustuvan ajattelun klusterin sisällä ja kuinka säilyttää täydellinen havainnoitavuus ilman telemetrian ylittämistä luokitusrajan yli.

Miksi perimeetrin tietoturva epäonnistuu puolustuksen mikropalveluklustereissa

Perimeetrin tietoturvamalli olettaa, että liikenne luotetun verkon rajan sisällä on turvallista. Monoliittisessa sovelluksessa tällä oletuksella on jonkin verran perusteltavuutta: on yksi prosessi, yksi luottamusraja ja suhteellisen vähän sisäisiä viestintäpolkuja suojattavana. Kubernetes-palveluverkkoarkkitehtuuriin käyttöönotetussa mikropalveluarkkitehtuurissa oletus romahtaa täysin. 20 palvelua ajava klusteri tuottaa noin 400 mahdollista palveluparia. Kaikkien ei pitäisi viestiä keskenään, mutta ilman nimenomaista valvontaa palvelutasolla ne kaikki voivat. Haavoittuvuus yhdessä palvelussa — riippuvuus, jossa on koodin etäsuoritusvirhe, virheellisesti konfiguroitu ympäristömuuttuja, joka paljastaa tunnistetiedot, päivittämätön peruskuva — antaa vastustajalle sivuliikekapasiteetin koko klusteriverkossa.

Vikamuoto ei ole teoreettinen. Toimitusketjun kompromissit, jotka kohdistuvat säiliötyökuormiin, ovat osoittaneet, että kun vastustajalla on koodin suoritusoikeus podin sisällä, he tutkivat klusteriverkkoa aggressiivisesti. Ilman vastavuoroista todennusta mikään ei estä vaarannettua podia kutsumasta sisäisiä API:ita suoraan: sillä on jo voimassa oleva klusterin IP-osoite, sen pyynnöt saapuvat luotetusta CIDR-alueesta ja kohdepalvelulla ei ole tapaa varmistaa kutsunteen identiteettiä. Perinteinen verkon segmentointi Kubernetes NetworkPolicyn avulla auttaa IP/portti-kerroksessa, mutta se ei estä laillisen podin identiteetin tekeytyrnistä sallitun osoitealueen sisällä eikä se valvo sovelluskerroksen rajoituksia sallituille operaatioille.

Palveluverkko ratkaisee tämän tekemällä kryptografisesta työkuorman identiteetistä pakollisen jokaiselle yhteydelle. Jokainen sivuvaunuproxy esittää SPIFFE Verifiable Identity Document (SVID) -asiakirjan — lyhytikäisen X.509-varmenteen, joka koodaa podin palvelutilin identiteetin — ja vaatii etäsivuvaunua esittämään voimassa olevan SVID:n vastineeksi ennen kuin sovellusdataa virtaa. Identiteettitarkistus tapahtuu siirtokerroksessa, sovellukselle läpinäkyvästi, eikä sitä voi ohittaa hyökkääjä, joka hallitsee vain säiliön sisällä olevaa sovellusprosessia. Sivuliike vähenee tasolta "saavuta mikä tahansa pod klusteriverkossa" tasoon "saavuta vain ne podit, joiden käytäntö nimenomaisesti sallii SVID:si lähteenä."

Palveluverkon valinta: Istio vs. Linkerd vs. Cilium ilmaraollisissa ympäristöissä

Kolme palveluverkkototeutusta on tuotantokäyttökelpoisia puolustuksen Kubernetes-käyttöönotoille, kullakin erilainen kompromissiprofiili. Istio on ominaisuuksiltaan kattavin: sen Envoy-pohjainen datataso tukee monipuolista L7-liikenteen hallintaa, mukaan lukien vian injektointi, uudelleenyritykset, virtakatkaisu, pyyntöjen peilaus ja hienojakoinen AuthorizationPolicy. Ohjauskerros — istiod — integroituu natiivisti SPIFFE/SPIRE:n kanssa ulkoista varmenteen myöntämistä varten, ja sen telemetriajakeluputki lähettää OpenTelemetry-yhteensopivia metriikoita ja jälkiä jokaisesta sivuvaunusta. Hintana on toiminnallinen monimutkaisuus: Istiolla on jyrkempi oppimiskäyrä, suurempi ohjauskerroksen jalanjälki ja Envoy-sivuvaunut, jotka kuluttavat enemmän muistia per pod kuin vaihtoehdot. Klustereille, joissa on 16+ GB RAM-muistia per solmu ja Envoy-konfiguraatiossa kokeneet tiimit, Istio:n käytäntöilmaisevuus on vaikea ylittää.

Linkerd ottaa päinvastaisen lähestymistavan. Sen datatason proxy on kirjoitettu Rustilla ja suunniteltu erittäin kevyeksi: jokainen linkerd-proxy-sivuvaunu käyttää 10–20 MB:n pysyvää muistia ja lisää alle 1 ms:n viiveen jokaiselle hypylle, verrattuna 50–100 MB:iin ja 0,5–3 ms:iin Envoyn osalta. Linkerdin nollakonfiguraatioinen mTLS on oletuksena päällä kaikessa verkotettussa liikenteessä ilman tarvittavaa PeerAuthentication-manifestia, mikä vähentää väärin konfiguroitujen selkotekstipoikkeusten riskiä. Kompromissina on, että Linkerdin käytäntömalli on vähemmän ilmaiseva HTTP-metodi- ja polkutasolla, ja sen ohjauskerros integroituu ulkoisiin SPIRE-myöntäjiin vähemmän suoraan kuin Istio. Rajoitetuille reunaklustereille, joissa on rajallinen per-solmu-RAM-muisti, Linkerdin proxy-tehokkuus on merkittävä toiminnallinen etu.

Cilium toimii eBPF-kerroksessa eikä sivuvaununa. Upottamalla käytäntöjen valvonnan Linux-ytimen eBPF-ohjelmiin, jotka on kiinnitetty jokaisen podin verkkoliittymään, Cilium saavuttaa lähes nollan per-työkuorman ylikuorman verkkokäytäntöjen valvonnalle ja perustason mTLS:lle. Sen CiliumNetworkPolicy-resurssi tukee SPIFFE-identiteettitietoisia sääntöjä integraatiolla SPIRE API:n kanssa, ja Hubble-havainnoitavuuskomponentti tarjoaa L4/L7-virtausnäkyvyyden klusterin sisällä. Ciliumin vahvuudet ovat suorituskyky ja sen saumaton kube-proxyn korvaaminen; sen rajoituksena on, että L7 HTTP/gRPC-käytäntöjen valvonta eBPF:n kautta on vähemmän kypsä kuin Istio:n Envoy-pohjainen vastine monimutkaisille auktorisointiskenaarioille. Käytännössä monet puolustusklusterit ajava Ciliumia CNI:nä verkkokäytäntöä ja salausta varten, ja Istio tai Linkerd on kerrostettu päälle L7-havainnoitavuutta ja hienojakoista palvelutason AuthorizationPolicy-valvontaa varten.

Vastavuoroinen TLS: varmenteen myöntäminen, kierrätys ja SPIFFE/SPIRE-integraatio

Vastavuoroinen TLS palveluverkossa tarkoittaa, että molemmat osapuolet jokaisessa yhteydessä todentavat toisensa X.509-varmenteilla ennen kuin mitään sovellusdataa vaihdetaan. Kriittinen kysymys puolustuskäyttöönotossa on, kuinka nämä varmenteet myönnetään, kuinka usein ne kierrätetään ja kuka hallitsee luottamuksen juurta. Alkuperäinen Istio käyttää omaa sisäänrakennettua varmenteiden myöntäjää (istiod CA), joka myöntää työkuormavarmenteita, jotka ovat oletuksena 24 tuntia voimassa. Puolustuskäyttöönotolle tämä on riittämätöntä kahdella tavalla: pääavain sijaitsee klusterin sisällä (vaarantunut istiod-prosessi paljastaa kaikki työkuormaidentiteetit) ja 24 tunnin TTL-arvot ovat liian pitkiä ympäristöihin, joissa nopea tunnistetietojen peruuttaminen saattaa olla tarpeen.

SPIRE tarjoaa oikean arkkitehtuurin puolustusyhteyksiin. SPIRE-palvelin toimii StatefulSet-kokoonpanona, jonka luottamusyhdiste ja rekisteröintimerkinnät tallennetaan tietosäilöön, joka voidaan pitää klusterin ulkopuolella. SPIRE-agentti toimii DaemonSet-kokoonpanona jokaisella solmulla ja käsittelee työkuorman todentamisen varmistamalla jokaisen podin Kubernetes-palvelutilitokenin API-palvelinta vastaan ennen SVID:n myöntämistä. Myönnetyillä SVID-asiakirjoilla on konfiguroitavat TTL-arvot — tuotantopuolustuskäyttöönotoissa käytetään 1 tunnin TTL-arvoja vakiotyökuormille ja 15 minuutin TTL-arvoja luokitettua dataa käsitteleville työkuormille — ja SPIRE-agentti käsittelee kierrätyksen automaattisesti, työntäen uuden SVID:n työkuormasokettiin ennen kuin nykyinen vanhenee. Verkon sivuvaunuproxy lukee SVID:n SPIFFE Workload API -soketin kautta ja esittää sen kaikissa lähtevissä TLS-yhteyksissä ilman sovellusohjelmakoodin muutoksia.

SPIRE:n integrointi Istion kanssa edellyttää istiod:n konfiguroimista käyttämään SPIRE:ä varmenteiden myöntäjänä ylävirtaisen CA-lisäosan rajapinnan kautta. Istio:n CustomCA-konfiguraatio osoittaa istiod:n SPIRE-palvelimen GRPC-porttiin, delegoiden kaikki SVID:n myöntämisen ja kierrätyksen SPIRE:lle, kun Istio käsittelee PeerAuthentication- ja AuthorizationPolicy-valvonnan. Tämä tehtävien erottaminen on tärkeää: SPIRE omistaa identiteetin elinkaaren (todentaminen, myöntäminen, kierrätys), kun taas Istio omistaa käytäntöelinkaaren (mitkä identiteetit voivat viestiä millä poluilla). Operaattori, joka peruuttaa työkuorman pääsyn, poistaa sen SPIRE-rekisteröintimerkinnän, mikä aiheuttaa seuraavan SVID-kierrätyksen epäonnistumisen, katkaisten työkuorman verkosta seuraavassa varmenteen uusimisessa ilman mitään käytäntömanifestin muutoksia.

Aiepohjainen liikennepolitiikka: itä-länsi-viestinnän sallimisluettelo

Oletus-kiellon periaate edellyttää, että mitään palveluiden välistä liikennettä ei sallita, ellei käytäntö nimenomaisesti salli sitä. Istiossa tämä toteutetaan klusterin laajuisella AuthorizationPolicy-manifestilla, jossa on tyhjä rules-lohko ja action: DENY — joka estää kaiken liikenteen — jonka jälkeen tulevat suppeat sallivat käytännöt jokaiselle lailliselle palveluparille. Jokainen salliva käytäntö nimeää lähdeprinsipaali (kutsuvan palvelun palvelutilin SPIFFE URI), kohdepalvelun ja tarkan joukon HTTP-metodeja tai gRPC-palvelunimiä, joihin kutsu on valtuutettu. Käytäntö, joka valtuuttaa anturidatan vastaanottopalvelun POST-osoittaamiseen datafuusio-API:lle, ei esimerkiksi salli sille myöskään GET-pyyntöjen tekemistä historiallisiin tietueisiin tai hallintopäätepisteiden kutsumiseen, vaikka molemmat ajavat samalla kohdepalvelun portilla. Rakeisuus on operaatiotasolla, ei pelkästään TCP-yhteystasolla.

Tämän käytäntöjoukon kirjoittaminen ja ylläpitäminen vaatii kurinalaisuutta. Klusteri, joka kasvaa 10:stä 30 palveluun 18 kuukauden aikana, kerää satoja sallimismerkintöjä, ja vanhentuneet merkinnät käytöstä poistettuja palveluja varten muodostuvat latenteiksi hyökkäyspinnoiksi. Kaksi käytäntöä estää tämän kertymisen. Ensiksi, käsittele AuthorizationPolicy-manifesteja koodina: tallenna ne samaan versionhallittuun tietovarastoon kuin sovellusmanifestit, edellytä vertaisarviointia jokaiselle uudelle sallimismerkinnälle ja tarkasta käytäntöjoukko neljännesvuosittain käynnissä olevien palvelujen luetteloa vasten. Toiseksi, käytä verkon käyttölokeja — jokainen hylätty pyyntö luo sivuvaunuun käyttölokimerkinnän, joka sisältää lähde-SVID:n, kohteen ja operaation — tunnistamaan lailliset liikennepolutt, joista käytäntö puuttuu, sen sijaan, että ne ohittaisivat verkon hiljaa. Tämä lokikirjaus tarjoaa myös monien puolustuksen tietoturvakehysten edellyttämän oikeuslääketieteellisen jäljityspolun, joka osoittaa, että käyttöoikeuspäätökset ovat tarkastettavissa.

Havainnoitavuus ilman tietovuotoja: klusterin sisäiset metriikat ja jäljitys

Palveluverkko luo monipuolista telemetriaa automaattisesti sivuvaunuproxyistaan: per-palvelu-pyyntöasteet, virheastelat HTTP-tilakoodeittain ja gRPC-tiloittain, latenssiprosentilit (p50, p95, p99), aktiivisten yhteyksien määrät ja TLS-kädenpuristusmetriikat. Kaupallisessa pilvideploy-käyttöönotoissa tämä telemetria välitetään tyypillisesti SaaS-havainnoitavuusalustalle. Luokitellussa sotilaallisessa klusterissa mikä tahansa telemetriajakeluputki, joka lähettää dataa luokitusrajan ulkopuolelle, on mahdollinen tietovuotovektori ja arkkitehtuurisesti kielletty. Koko havainnoitavuuspinon on oltava käyttöön otettu klusterin rajan sisällä, ja sen on itsessään oltava käyttöoikeuksiltaan valvottuna samojen verkkokäytäntöjen avulla, jotka ohjaavat sovelluksen liikennettä.

Vakiomuotoinen klusterin sisäinen havainnoitavuuspino palveluverkolle koostuu Prometheuksesta metriikoiden keräämiseen, Grafanasta visualisointiin sekä Jaegeristä tai Temposta hajautettuun jäljitykseen. Prometheus kerää Envoy-tilastoendpointin (portti 15090) tai linkerd-proxy-metriikaendpointin kaikilta verkotetuilta podeilta konfiguroitavalla intervallilla. Grafana muodostaa yhteyden yksinomaan klusterin sisäisiin Prometheus- ja Loki-instansseihin — ulkoisia tietolähdeyhteyksiä ei konfiguroida. Jaeger vastaanottaa jälkijaksoja, jotka Envoy-sivuvaunu välittää Zipkin- tai OpenTelemetry-protokollalla klusterin paikalliseen kerääjäpäätepisteeseen. Kaikki pysyvä tallennustila metriikoille, jäljille ja lokeille käyttää klusterin paikallisia PersistentVolumeja, jotka on tuettu salatulla lohkotallennustilalla. Seurantanimiavaruudessa on NetworkPolicy, joka estää kaiken ulospäin suuntautuvan liikenteen ulkoisiin IP-alueisiin, tehden telemetrian klusterin ulkopuolelle siirtymisen arkkitehtuurisesti mahdottomaksi, vaikka virheellisesti konfiguroitu jakeluputki otettaisiin käyttöön.

Puolustustyökuormille kovennetuissa Kubernetes-klustereissa on syytä huomata, että havainnoitavuuspino on myös hankittava ilmaraollisista rekistereistä. Prometheus, Grafana, Jaeger ja Loki -kuvat on peilattava sisäiseen rekisteriin varmennetuilla tiivisteillä ennen klusterin sijoittamista luokitusrajan taakse. Kuvien hakukäytännöt on asetettava Never- tai IfNotPresent-tilaan ymmärtäen, että kuvia ei koskaan päivitetä ulkoisesta lähteestä. Mikä tahansa päivitys havainnoitavuuspinoon edellyttää virallista muutoksenhallintaprosessia, joka tuo päivitetyt kuvat ilmaraon läpi eikä yksinkertaista Helm-kaavion päivitystä julkista kaaviovarastoa vastaan.

Sivuvaunun ylikuorma rajoitetuissa puolustuksen reunaklustereissa

Operaatioiden lähelle sijoitetut reunaklusterit — jotka ajavat pienikokoisia palvelimia tai järkytyskestäviä laskenta-alustoja, joissa on 32–64 GB RAM-muistia ja 4–8 solmua — kohtaavat resurssitavoitteen, joka tekee sivuvaunun ylikuormasta todellisen insinööriongelman eikä teoreettisen huolenaiheen. Istio Envoy -sivuvaunu vakiotilassa kuluttaa 50–100 MB:n asukkaan joukon kokoa ja jopa 0,5 vCPU:ta suuriläpimenon kausina. Klusteri, joka ajaa 40 podia, kuluttaa 2–4 GB:n kokonaissivuvaunumuistia, noin 6–12 % 32 GB:n klusterin kokonais-RAM-muistista. Ohjauskerros itsessään — istiod, Prometheus, Grafana, Jaeger — lisää toisen 2–4 GB:n, tuoden verkon infrastruktuurin kokonaisylikuorman 15–25 %:iin klusterin muistista ennen kuin mitään sovellustyökuormia otetaan huomioon.

Kolme vaihtoehtoa vähentää tätä ylikuormaa rajoitetuissa käyttöönotoissa. Ensiksi, Linkerdin Rust-pohjainen proxy on tehokkain saatavilla oleva sivuvaunu: 10–20 MB per pod Envoyn 50–100 MB:n sijaan, ja viiveen ylikuorma alle 1 ms per hyppy. Klustereille, joissa L7-käytäntörakeisuusvaatimukset voidaan täyttää Linkerdin käytäntömallilla, muistisäästöt ovat huomattavat. Toiseksi, Istio:n ambient mesh -tila (saatavilla Istio 1.22:sta alkaen) poistaa per-pod-sivuvaunut kokonaan, korvaten ne per-solmu-ztunnel-proxyllä, joka käsittelee mTLS:ää kaikille solmun podeille. Ambient-tila vähentää per-pod-ylikuorman lähes nollaan kustannuksena siirtää käytäntöjen valvonta per-työkuorma-sivuvaunuista per-solmu-proxyihin, mikä tarjoaa hieman karkeampaa käytäntörakeisuutta työkuormille, jotka tarvitsevat per-pyyntö-auktorisointipäätöksiä. Kolmanneksi, valikoiva ruiskutus — sivuvaunujen ruiskuttaminen vain podeihin, jotka vaativat L7-käytäntöjen valvontaa, ja Ciliumin eBPF-pohjaisen L4-salauksen käyttäminen muille — tasapainottaa valvontarakeisuuden suhteessa resurssien kulutukseen heterogeenisille klusterityökuormille.

Sivuvaunun resurssienkulutuksen ja puolustuksen CI/CD-putkien salaisuustenhallinnan välinen vuorovaikutus on syytä mainita erikseen. Salaisuuksien ruiskutussivuvaunut (Vault Agent Injector, Secrets Store CSI Driver) lisäävät toisen säiliön per pod. Reunaklusteri, joka ajaa sekä verkon sivuvaunua että salaisuuksien ruiskutussivuvaunua per sovelluspodia, käyttää kaksi infrastruktuurisäiliötä jokaista sovellusäiliötä kohden, kaksinkertaistaen säiliöiden määrän ja lisäten 60–120 MB:n infrastruktuuriylikuorman per podipari. Konsolidointi on mahdollista: SPIRE-agentti voi toimia sekä verkon identiteettimyöntäjänä että työkuorman salaisuuksien toimitusmenetelmänä salaisuuksille, jotka voidaan ilmaista SVID-valtuutettuina Vault-rooleina, poistamalla erillinen salaisuuksien ruiskutussivuvaunu niiltä työkuormilta.

Palveluverkon käytäntöjen integrointi RBAC:n ja salaisuustenhallinnan kanssa

Kubernetes RBAC hallitsee, kuka voi lukea ja muokata Kubernetes API -objekteja — mukaan lukien AuthorizationPolicy-, PeerAuthentication- ja verkkoasetusresurssit, jotka määrittelevät palveluverkon tietoturvaasennon. Jos RBAC-konfiguraatio sallii laajan joukon prinsipaaleita muokata AuthorizationPolicy-objekteja, verkon käyttöoikeuskerros voidaan heikentää millä tahansa näistä prinsipaaleista. Oikea puolustuskäyttöönotto käsittelee verkon käytäntömanifesteja korkean arvon tietoturvaobjekteina: vain CI/CD-palvelutilillä, joka soveltaa manifesteja versionhallinnan käytäntötietovarastosta, tulisi olla kirjoitusoikeus AuthorizationPolicy- ja PeerAuthentication-resursseihin, ja vain klusterin ylläpitäjillä tulisi olla mahdollisuus muokata SPIRE-rekisteröintimerkintöjä. Kaikilla muilla prinsipaaleilla — mukaan lukien yksittäiset sovelluspalvelutilit — tulisi olla vain luku- tai ei lainkaan pääsy näihin objekteihin.

Verkon identiteettikerroksen ja salaisuuksienhallinnankerroksen välinen suhde on kaksisuuntainen. Verkko käyttää SPIFFE SVID -asiakirjoja todentamaan palveluiden väliset kutsut siirtokerroksessa. Salaisuuksien hallinta (Vault, Kubernetes Secrets Store CSI Driver) käyttää näitä samoja SVID-pohjaisia identiteettejä määrittämään, mitkä työkuormat voivat vastaanottaa mitkä salaisuudet sovellustasolla. Työkuorma, jolla on SPIFFE ID spiffe://cluster.local/ns/fusion/sa/data-processor, voidaan kartoittaa Vault-rooliin, joka myöntää lukuoikeuden täsmälleen niihin tietokantatunnisteisiin, joita kyseinen palvelu tarvitsee — eikä mihinkään muuhun. Tämä tarkoittaa, että verkon identiteettijärjestelmä ja salaisuuksien toimitusjärjestelmä jakavat yhden autoritatiivisen työkuorman identiteettilähteen, poistaen riskin epäjohdonmukaisuudesta, jossa työkuormalle sallitaan verkkopääsy mutta ei salaisuuksia sen käyttämiseen, tai päinvastoin. Tämän yhteensopivuuden ylläpitäminen edellyttää, että SPIRE-rekisteröintimerkinnät, Vault-roolimääritelmät ja verkon AuthorizationPolicy-manifestit päivitetään kaikki yhdessä, kun palvelu lisätään, muokataan tai poistetaan käytöstä.

Tarkastuslokit yhdistävät kolme järjestelmää yhteensopivuutta ja tapahtumiin reagointia varten. Verkon sivuvaunu kirjaa jokaisen käyttöoikeuspäätöksen — salli tai kiellä — varmennetulla lähde-SVID:llä, kohteella, operaatiolla ja aikaleimalla. Vault kirjaa jokaisen salaisuuksien käytön pyytävällä identiteetillä ja salaisuuspolulla. Kubernetes API -palvelimen tarkastuslokit tallentavat jokaisen RBAC-hallitun API-kutsun. Yhdessä nämä kolme lokivirtaa tarjoavat täydellisen tarkastuspolun "mistä verkkokutsu tehtiin" kautta "mihin salaisuuksiin pääsi käsiksi tuloksena" "kuka muutti käytäntöä, joka hallitsi molempia." Puolustusympäristöissä, jotka toimivat virallisten hyväksymisvaatimusten alaisena, tämä jäljitettävyys identiteetti-, käyttöoikeus- ja salaisuuskerrosten välillä on usein ehdoton vaatimustenmukaisuusedellytys eikä toiminnallinen lisä.