
Egy FedRAMP-engedélyezési csomag éveken át mindenekelőtt egy dolog volt: rengeteg dokumentum. Több száz oldalas rendszerbiztonsági tervek, Word-sablonokban megírt kontrollleírások, Excelben vezetett leltárak és teszteredmények. Még 2025-ben is szinte teljes egészében ezekre a sablonokra épültek a Rev5 szerinti engedélyezések – annak ellenére, hogy az OSCAL már régóta létezett géppel olvasható alternatívaként.
2026 januárjában a FedRAMP az RFC-0024-gyel elindította az irányváltást: az engedélyezési adatokat dokumentumhalmok helyett strukturált, géppel olvasható adatként kell benyújtani. Az ügynökségek számára ez gyorsabb átvizsgálást és összehasonlítható csomagokat jelent. A felhőszolgáltatók számára olyan átállást, amelyet sokkal jobb korán megtervezni, mint későn.
A végleges szabályhoz vezető út maga is tanulságos példája a nyilvános szabványosításnak. Az eredeti javaslat már 2026. szeptember 30-ra szigorú határidőket tűzött ki. A 2026. március 11-én lezárult véleményezési időszakban a szolgáltatók szinte egyöntetűen több felkészülési időt kértek.
A FedRAMP reagált: a 2026 márciusában közzétett átmeneti eredmény kitolta a határidőket. Ezután mindent egységes szerkezetbe foglaltak a 2026. június végén közzétett végleges Consolidated Rules for 2026 (CR26) szabályokban, amelyek a követelményeket A-tól D-ig terjedő tanúsítási osztályokba sorolják. Az üzenet változatlan: a géppel olvashatóság eljön – csak az ütemterv lett reálisabb.
A végleges CR26-ütemterv számít; a korábbi, osztályonkénti formátumhatáridőket tartalmazó átmeneti tervezetek érvényüket vesztették.
A tervezés szempontjából fontos: aki 2027-ben új engedélyezést céloz meg, az gyakorlatilag már 2026-ban az új formátumokkal dolgozik – a csomag előkészítése, a hiányosságelemzések és a tesztelés jóval a határidő előtt elkezdődik.
A végleges szabályok a géppel olvashatóságot olyan JSON-dokumentumokhoz kötik, amelyek a közzétett FedRAMP-sémák szerint validálnak – a FedRAMP nem ír elő konkrét szerkesztőeszközt. A gyakorlatban az út az OSCAL-on keresztül vezet: ez a NIST-szabvány a bevett nyílt adatmodell pontosan ehhez a tartalomhoz, a FedRAMP az OSCAL-közösséggel együttműködve dolgozik sablonokon és forrásanyagokon, és az eszközök ökoszisztémája is itt növekszik a leggyorsabban – az OSCAL-eszközök körképéről szóló bejegyzésünk áttekintést ad.
Azt, hogyan illeszkednek egymáshoz a dokumentummodellek – a katalógustól a profilon át az SSP-ig és az értékelésig –, a Mi az OSCAL? című bevezetőnk mutatja be.
A strukturált megfelelési adatokkal végzett munkánk során egy egyszerű sorrend bizonyult be. Attól függetlenül működik, hogy a cél a FedRAMP vagy egy másik, géppel olvashatósági követelményeket támasztó program.
Pontosan ezért építjük a Secanit: egy olyan platformot, ahol az engedélyezési adatok kezdettől fogva strukturáltak – forrásokkal, jóváhagyásokkal és előzményekkel. Ha az átállást tervezi, beszéljen velünk.
A Secani egyetlen közös munkaterületen köti össze a hatóköröket, a bizonyítékokat, a feladatokat és az MI-ügynököket.
Az OSCAL strukturált adatokká alakítja a megfelelési dokumentumokat: nyolc dokumentummodell, három formátum és egy ökoszisztéma, amely a szabályozás standardjává válik.
Az OLIR a megfeleltetési tartalmat és annak irányítását biztosítja. Az OSCAL azt a géppel olvasható struktúrát adja, amellyel ezek a megfeleltetések hiányelemzésben, a bizonyítékok újrafelhasználásában és a változáshatás-elemzési munkafolyamatokban használhatók.
Minden OSCAL-validátor azt állítja, hogy validálja az OSCAL-t. Mi számba vettük a NIST forrásaiban szereplő mind a 348 megkötés-előfordulást, mindegyiket bizonyítottuk vagy kizártuk, majd ténylegesen lefuttattuk az összehasonlítást a Java CLI-vel.