Prejsť na obsah

RAG správa

RAG správa klasifikuje každú príslušnú požiadavku EÚ ako Zelenú (splnená), Oranžovú (riziková) alebo Červenú (nesplnená) — bežný formát analýz medzier v zhode.

Definícia
RAG správa klasifikuje každú príslušnú požiadavku EÚ ako Zelenú (splnená), Oranžovú (riziková) alebo Červenú (nesplnená) — bežný formát analýz medzier v zhode.

RAG správa (z angličtiny Red-Amber-Green Report, doslova Správa Červená-Oranžová-Zelená) je štruktúrovaný hodnotiaci dokument využívajúci trojfarebný semaforový systém na vyjadrenie stavu zhody každej jednotlivej požiadavky príslušnej smernice alebo nariadenia EÚ vzhľadom na súčasný návrh produktu. Ide o široko používaný formát výstupu analýz medzier v zhode hardvéru — nie o formát predpísaný právom EÚ —, pretože premieňa komplexné viacosmernicové technické hodnotenia na prehľad zrozumiteľný vedeniu, ktorý možno použiť na stanovenie priorít nápravy a zdôvodnenie inžinierskeho rozpočtu.

Tri klasifikácie RAG

FarbaVýznamPotrebná akcia
🟢 ZelenáPožiadavka je súčasným návrhom plne splnená. Dôkaz je zdokumentovaný (skúšobná správa, revízia návrhu, materiálové vyhlásenie atď.)Žiadna — zdokumentujte dôkaz v Technickej dokumentácii
🟡 OranžováPožiadavka je čiastočne splnená, alebo zhoda je podmienečná/neoverená. Návrh môže byť zhodný, ale dôkaz chýba alebo predpoklad potrebuje validáciu.Potrebné prešetrenie — buď doplňte chýbajúci dôkaz alebo preprojektujte označený prvok
🔴 ČervenáPožiadavka nie je súčasným návrhom splnená. Existuje konkrétna medzera, ktorú nemožno uzavrieť bez zmeny návrhu, nahradenia komponentu alebo úpravy procesu.Potrebná náprava — medzera musí byť uzavretá, kým môže produkt legálne niesť označenie CE

Štruktúra RAG správy o zhode hardvéru

Pre pripojený hardvérový produkt podliehajúci viacerým smerniciam je RAG správa zvyčajne štruktúrovaná nasledovne:

RAG správa o zhode — [Názov produktu] Rev. [X]
Spracoval: [Meno inžiniera, kvalifikácia]
Preskúmal: [Hlavný bezpečnostný architekt / vedúci zhody]
Dátum: [RRRR-MM-DD]

1. ROZSAH
   - Popis produktu a zamýšľané použitie
   - Zoznam hodnotených aplikovateľných smerníc a nariadení
   - Metodológia hodnotenia a uvádzané normy

2. ZHRNUTIE PRE VEDENIE
   - Súhrnná tabuľka: celkový počet Zelená / Oranžová / Červená podľa smernice
   - Celkový verdikt zhody
   - Odporúčané poradie priorít nápravy

3. PODROBNÉ ZISTENIA — podľa smerníc
   [Pre každú aplikovateľnú smernicu tabuľka požiadaviek:]
   | Požiadavka | Článok/bod | RAG stav | Zistenia | Dôkaz/Odporúčanie |
   |---|---|---|---|---|
   | Dôvernosť uložených kľúčov a údajov | CRA Príloha I, časť I bod 2 písm. e) | 🔴 Červená | MCU (STM32F4) nemá Secure Element ani TrustZone. Zdieľaný kľúč uložený vo flash. | Nahradiť MCU za STM32U5 (TrustZone-M) a pridať Secure Element STSAFE-A110 |
   | Ochrana pred neoprávneným prístupom (autentifikácia) | CRA Príloha I, časť I bod 2 písm. d) | 🔴 Červená | MAC adresa použitá ako identita — klonovateľná. | Implementovať provisioning certifikátov zariadenia STSAFE-A110 pri výrobe |
   | Integrita softvéru a bezpečná distribúcia aktualizácií | CRA Príloha I, časť I bod 2 písm. f), časť II bod 7 | 🟡 Oranžová | OTA mechanizmus existuje, ale podpisový kľúč uložený v softvéri. | Potrebné hardvérové úložisko kľúčov — vyrieši sa pridaním STSAFE-A110 |
   | Politika koordinovaného zverejňovania informácií o zraniteľnostiach a kontakt | CRA Príloha I, časť II body 5 a 6 | 🟢 Zelená | security.txt prítomný na doméne produktu, PSIRT kontakt zriadený | Zdokumentovať v Technickej dokumentácii |

4. RIZIKOVÁ MATICA KOMPONENTOV
   [Tabuľka na úrovni BOM identifikujúca, ktoré komponenty vyhovujú, nevyhovujú alebo vyžadujú výmenu]

5. PLÁN NÁPRAVY
   - Prioritizovaný zoznam potrebných zmien
   - Odhadované inžinierske úsilie (osobodní)
   - Odhadovaný rozpočtový rozsah
   - Časový harmonogram dosiahnutia plnej zhody

6. REFERENCIE
   - Smernice a nariadenia s dátumami uverejnenia
   - Normy s dátumami vydaní

Prečo sú RAG správy dôležité aj mimo zhody

Formát RAG správy súčasne slúži trom skupinám čitateľov:

Pre inžiniersky tím: Presná špecifikácia na úrovni požiadaviek o tom, čo treba zmeniť a prečo — eliminuje nejednoznačnosť medzi zámerom zhody a implementáciou.

Pre CTO/riaditeľa inžinierstva: Dôkazmi podložený obchodný prípad pre investíciu do redesignu. Počet nálezov „Červená“ a odhad nákladov na nápravu poskytujú dáta potrebné na zdôvodnenie rozpočtu, najmä voči protiargumentu „aktualizácia firmvéru to napraví“.

Pre regulátora: Orgány dohľadu nad trhom žiadajú technickú dokumentáciu a EÚ vyhlásenie o zhode, nie RAG správu. RAG správa môže túto dokumentáciu podporiť tým, že ukáže, že výrobca posúdil každú požiadavku, identifikoval medzery a prijal nápravné opatrenia.

Oficiálne referencie