Ondernemingsnetwerkfunksie Virtualiseringsinfrastruktuursagteware

Produk inligting

Spesifikasies

• NFVIS sagteware weergawe: 3.7.1 en later
• RPM-ondertekening en handtekeningverifikasie word ondersteun
• Veilige selflaai beskikbaar (by verstek gedeaktiveer)
• Secure Unique Device Identification (SUDI) meganisme gebruik

Veiligheidsoorwegings

Die NFVIS-sagteware verseker sekuriteit deur verskeie
meganismes:

• Beeld Tamper Beskerming: RPM-ondertekening en handtekeningverifikasie
  vir alle RPM-pakkette in die ISO en opgradeer beelde.
• RPM-ondertekening: Alle RPM-pakkette in die Cisco Enterprise NFVIS ISO
  en opgraderingsbeelde word onderteken om kriptografiese integriteit te verseker en
  egtheid.
• RPM Handtekening Verifikasie: Handtekening van alle RPM pakkette is
  geverifieer voor installasie of opgradering.
• Verifikasie van beeldintegriteit: Hash van die Cisco NFVIS ISO-beeld
  en opgradering beeld word gepubliseer om integriteit van addisionele te verseker
  nie-RPM files.
• ENCS Secure Boot: Deel van die UEFI-standaard, verseker dat die
  toestel selflaai slegs met behulp van betroubare sagteware.
• Veilige Unieke Toestelidentifikasie (SUDI): Verskaf die toestel
  met 'n onveranderlike identiteit om die egtheid daarvan te verifieer.

Installasie

Volg hierdie stappe om die NFVIS-sagteware te installeer:

1. Maak seker dat die sagtewarebeeld nie tampered met deur
   die handtekening en integriteit daarvan te verifieer.
2. As jy Cisco Enterprise NFVIS 3.7.1 en later gebruik, maak seker dat
   die handtekeningverifikasie slaag tydens installasie. As dit misluk,
   die installasie sal gestaak word.
3. As u vanaf Cisco Enterprise NFVIS 3.6.x opgradeer na Release
   3.7.1, die RPM-handtekeninge word tydens die opgradering geverifieer. As die
   handtekeningverifikasie misluk, 'n fout word aangeteken, maar die opgradering is
   voltooi.
4. As u vanaf Vrystelling 3.7.1 na latere vrystellings opgradeer, sal die RPM
   handtekeninge word geverifieer wanneer die opgraderingsbeeld geregistreer is. As
   die handtekeningverifikasie misluk, die opgradering word gestaak.
5. Verifieer die hash van die Cisco NFVIS ISO-beeld of opgradeerbeeld
   met behulp van die opdrag: /usr/bin/sha512sum
<image_filepath>. Vergelyk die hash met die gepubliseerde
   hash om integriteit te verseker.

Veilige selflaai

Veilige selflaai is 'n kenmerk beskikbaar op ENCS (by verstek gedeaktiveer)
wat verseker dat die toestel slegs met betroubare sagteware begin. Om
aktiveer veilige selflaai:

1. Verwys na die dokumentasie oor Secure Boot of Host vir meer
   inligting.
2. Volg die verskafde instruksies om veilige selflaai op jou te aktiveer
   toestel.

Veilige unieke toestelidentifikasie (SUDI)

SUDI voorsien NFVIS van 'n onveranderlike identiteit, wat dit verifieer
dit is 'n ware Cisco produk en verseker sy erkenning in die
kliënt se voorraadstelsel.

Gereelde vrae

V: Wat is NFVIS?

A: NFVIS staan ​​vir Network Function Virtualization
Infrastruktuur sagteware. Dit is 'n sagteware platform wat gebruik word om te ontplooi
en bestuur virtuele netwerkfunksies.

V: Hoe kan ek die integriteit van die NFVIS ISO-beeld of
beeld op te gradeer?

A: Om die integriteit te verifieer, gebruik die opdrag
/usr/bin/sha512sum <image_filepath> en vergelyk
die hash met die gepubliseerde hash verskaf deur Cisco.

V: Is veilige selflaai by verstek op ENCS geaktiveer?

A: Nee, veilige selflaai is by verstek op ENCS gedeaktiveer. dit is
aanbeveel om veilige selflaai vir verbeterde sekuriteit te aktiveer.

V: Wat is die doel van SUDI in NFVIS?

A: SUDI voorsien NFVIS van 'n unieke en onveranderlike identiteit,
die egtheid daarvan as 'n Cisco-produk te verseker en die fasilitering daarvan
herkenning in die kliënt se voorraadstelsel.

Veiligheidsoorwegings
Hierdie hoofstuk beskryf die sekuriteitskenmerke en -oorwegings in NFVIS. Dit gee 'n hoë-vlak oorview van sekuriteitverwante komponente in NFVIS om 'n sekuriteitstrategie te beplan vir ontplooiings spesifiek vir jou. Dit het ook aanbevelings oor die beste praktyke vir sekuriteit om die kernelemente van netwerksekuriteit af te dwing. Die NFVIS-sagteware het sekuriteit ingebed vanaf installasie deur alle sagtewarelae. Die daaropvolgende hoofstukke fokus op hierdie out-of-the-box sekuriteitsaspekte soos geloofsbriewebestuur, integriteit en tamper beskerming, sessiebestuur, veilige toesteltoegang en meer.

· Installasie, op bladsy 2 · Veilige Unieke Toestelidentifikasie, op bladsy 3 · Toesteltoegang, op bladsy 4

Sekuriteitsoorwegings 1

Installasie

Veiligheidsoorwegings

· Infrastruktuurbestuursnetwerk, op bladsy 22 · Plaaslik gestoor inligtingbeskerming, op bladsy 23 · File Oordrag, op bladsy 24 · Aantekening, op bladsy 24 · Virtuele masjiensekuriteit, op bladsy 25 · VM-isolasie en hulpbronvoorsiening, op bladsy 26 · Veilige ontwikkelingslewensiklus, op bladsy 29

Installasie
Om te verseker dat die NFVIS-sagteware nie tampgestel met , word die sagtewarebeeld geverifieer voor installasie deur die volgende meganismes te gebruik:

Beeld Tamper beskerming
NFVIS ondersteun RPM-ondertekening en handtekeningverifikasie vir alle RPM-pakkette in die ISO en opgraderingsbeelde.

RPM Ondertekening

Alle RPM-pakkette in die Cisco Enterprise NFVIS ISO en opgraderingsbeelde word onderteken om kriptografiese integriteit en egtheid te verseker. Dit waarborg dat die RPM-pakkette nie tampmet en die RPM-pakkette is van NFVIS. Die private sleutel wat gebruik word om die RPM-pakkette te onderteken, word deur Cisco geskep en veilig onderhou.

RPM-handtekeningverifikasie

NFVIS-sagteware verifieer die handtekening van al die RPM-pakkette voor 'n installasie of opgradering. Die volgende tabel beskryf die Cisco Enterprise NFVIS-gedrag wanneer die handtekeningverifikasie tydens 'n installasie of opgradering misluk.

Scenario

Beskrywing

Cisco Enterprise NFVIS 3.7.1 en later installasies As die handtekeningverifikasie misluk tydens die installering van Cisco Enterprise NFVIS, word die installasie gestaak.

Cisco Enterprise NFVIS-opgradering van 3.6.x na Vrystelling 3.7.1

Die RPM-handtekeninge word geverifieer wanneer die opgradering uitgevoer word. As die handtekeningverifikasie misluk, word 'n fout aangeteken, maar die opgradering is voltooi.

Cisco Enterprise NFVIS-opgradering vanaf Vrystelling 3.7.1 Die RPM-handtekeninge word geverifieer wanneer die opgradering

na latere vrystellings

beeld is geregistreer. As die handtekeningverifikasie misluk,

die opgradering word gestaak.

Verifikasie van beeldintegriteit
RPM-ondertekening en handtekeningverifikasie kan slegs gedoen word vir die RPM-pakkette wat beskikbaar is in die Cisco NFVIS ISO en opgradeer beelde. Om die integriteit van al die bykomende nie-RPM te verseker files beskikbaar in die Cisco NFVIS ISO-beeld, word 'n hash van die Cisco NFVIS ISO-beeld saam met die beeld gepubliseer. Net so word 'n hash van die Cisco NFVIS-opgraderingsbeeld saam met die beeld gepubliseer. Om te verifieer dat die hash van Cisco

Sekuriteitsoorwegings 2

Veiligheidsoorwegings

ENCS Secure Boot

NFVIS ISO-beeld of opgraderingsbeeld pas by die hash wat deur Cisco gepubliseer is, voer die volgende opdrag uit en vergelyk die hash met die gepubliseerde hash:
% /usr/bin/sha512sumFile> c2122783efc18b039246ae1bcd4eec4e5e027526967b5b809da5632d462dfa6724a9b20ec318c74548c6bd7e9b8217ce96b5ece93dcdd74fda5e01bb382ad607
<ImageFile>
ENCS Secure Boot
Veilige selflaai is deel van die Unified Extensible Firmware Interface (UEFI)-standaard wat verseker dat 'n toestel net selflaai met 'n sagteware wat deur die Original Equipment Manufacturer (OEM) vertrou word. Wanneer NFVIS begin, kontroleer die firmware die handtekening van die opstartsagteware en die bedryfstelsel. As die handtekeninge geldig is, begin die toestel, en die firmware gee die beheer aan die bedryfstelsel.
Veilige selflaai is beskikbaar op die ENCS, maar is by verstek gedeaktiveer. Cisco beveel aan dat u veilige selflaai aktiveer. Vir meer inligting, sien Veilige opstart van gasheer.
Veilige unieke toestelidentifikasie
NFVIS gebruik 'n meganisme bekend as Secure Unique Device Identification (SUDI), wat dit van 'n onveranderlike identiteit voorsien. Hierdie identiteit word gebruik om te verifieer dat die toestel 'n egte Cisco-produk is, en om te verseker dat die toestel welbekend is aan die kliënt se voorraadstelsel.
Die SUDI is 'n X.509v3-sertifikaat en 'n gepaardgaande sleutelpaar wat in hardeware beskerm word. Die SUDI-sertifikaat bevat die produkidentifiseerder en reeksnommer en is gewortel in Cisco Public Key Infrastructure. Die sleutelpaar en die SUDI-sertifikaat word tydens vervaardiging in die hardewaremodule ingevoeg, en die private sleutel kan nooit uitgevoer word nie.
Die SUDI-gebaseerde identiteit kan gebruik word om geverifieerde en outomatiese konfigurasie uit te voer deur gebruik te maak van Zero Touch Provisioning (ZTP). Dit maak veilige, afgeleë aanboord van toestelle moontlik, en verseker dat die orkestrasiebediener met 'n egte NFVIS-toestel praat. 'n Backend-stelsel kan 'n uitdaging aan die NFVIS-toestel uitreik om sy identiteit te bekragtig en die toestel sal op die uitdaging reageer deur sy SUDI-gebaseerde identiteit te gebruik. Dit stel die backend-stelsel in staat om nie net teen sy voorraad te verifieer dat die regte toestel op die regte plek is nie, maar ook geënkripteerde konfigurasie verskaf wat slegs deur die spesifieke toestel oopgemaak kan word, en sodoende vertroulikheid tydens vervoer verseker.
Die volgende werkvloeidiagramme illustreer hoe NFVIS SUDI gebruik:

Sekuriteitsoorwegings 3

Toesteltoegang Figuur 1: Plug and Play (PnP) Bedienerverifikasie

Veiligheidsoorwegings

Figuur 2: Plug and Play-toestelstawing en magtiging

Toegang tot toestel
NFVIS bied verskillende toegangsmeganismes, insluitend konsole sowel as afstandtoegang gebaseer op protokolle soos HTTPS en SSH. Elke toegangsmeganisme moet noukeurig hersien wordviewed en gekonfigureer. Maak seker dat slegs die vereiste toegangsmeganismes geaktiveer is en dat hulle behoorlik beveilig is. Die sleutelstappe om beide interaktiewe en bestuurstoegang tot NFVIS te verseker, is om die toesteltoeganklikheid te beperk, die vermoëns van die toegelate gebruikers te beperk tot wat vereis word, en die toegelate metodes van toegang te beperk. NFVIS verseker dat die toegang slegs aan geverifieerde gebruikers verleen word en dat hulle net die gemagtigde aksies kan uitvoer. Toesteltoegang word aangeteken vir ouditering en NFVIS verseker die vertroulikheid van plaaslik gestoor sensitiewe data. Dit is van kritieke belang om die toepaslike kontroles daar te stel om ongemagtigde toegang tot NFVIS te voorkom. Die volgende afdelings beskryf die beste praktyke en konfigurasies om dit te bereik:
Sekuriteitsoorwegings 4

Veiligheidsoorwegings

Gedwonge wagwoordverandering by eerste aanmelding

Gedwonge wagwoordverandering by eerste aanmelding
Verstek geloofsbriewe is 'n gereelde bron van produk sekuriteit voorvalle. Kliënte vergeet dikwels om die verstek aanmeldbewyse te verander en laat hul stelsels oop vir aanval. Om dit te voorkom, word die NFVIS-gebruiker gedwing om die wagwoord te verander na die eerste aanmelding met behulp van die verstek geloofsbriewe (gebruikersnaam: admin en wagwoord Admin123#). Vir meer inligting, sien Toegang tot NFVIS.
Beperk aanmeldkwesbaarhede
U kan die kwesbaarheid vir woordeboek- en Denial of Service (DoS)-aanvalle voorkom deur die volgende kenmerke te gebruik.
Afdwinging van 'n sterk wagwoord
'n Verifikasiemeganisme is net so sterk soos sy geloofsbriewe. Om hierdie rede is dit belangrik om te verseker dat gebruikers sterk wagwoorde het. NFVIS kontroleer dat 'n sterk wagwoord volgens die volgende reëls opgestel is: Wagwoord moet bevat:
· Minstens een hoofletterkarakter · Ten minste een kleinletterkarakter · Minstens een nommer · Ten minste een van hierdie spesiale karakters: hash (#), onderstreep (_), koppelteken (-), asterisk (*) of vraag
merk (?) · Sewe karakters of meer · Die wagwoordlengte moet tussen 7 en 128 karakters wees.
Stel minimum lengte vir wagwoorde op
Gebrek aan wagwoordkompleksiteit, veral wagwoordlengte, verminder die soekruimte aansienlik wanneer aanvallers gebruikerswagwoorde probeer raai, wat brute-force-aanvalle baie makliker maak. Die admin gebruiker kan die minimum lengte wat vereis word vir wagwoorde van alle gebruikers instel. Die minimum lengte moet tussen 7 en 128 karakters wees. By verstek is die minimum lengte wat vereis word vir wagwoorde gestel op 7 karakters. CLI:
nfvis(config)# rbac-verifikasie min-pwd-lengte 9
API:
/api/config/rbac/authentication/min-pwd-length
Konfigureer Wagwoord Leeftyd
Die wagwoordleeftyd bepaal hoe lank 'n wagwoord gebruik kan word voordat die gebruiker dit moet verander.

Sekuriteitsoorwegings 5

Beperk vorige wagwoordhergebruik

Veiligheidsoorwegings

Die admin-gebruiker kan minimum en maksimum leeftydwaardes vir wagwoorde vir alle gebruikers opstel en 'n reël afdwing om hierdie waardes na te gaan. Die verstek minimum leeftydwaarde is gestel op 1 dag en die verstek maksimum leeftydwaarde is gestel op 60 dae. Wanneer 'n minimum leeftydwaarde opgestel is, kan die gebruiker nie die wagwoord verander voordat die gespesifiseerde aantal dae verby is nie. Net so, wanneer 'n maksimum leeftydwaarde opgestel is, moet 'n gebruiker die wagwoord verander voordat die gespesifiseerde aantal dae verbygaan. As 'n gebruiker nie die wagwoord verander nie en die gespesifiseerde aantal dae het verloop, word 'n kennisgewing aan die gebruiker gestuur.
Let wel Die minimum en maksimum leeftydwaardes en die reël om vir hierdie waardes na te gaan, word nie op die admin gebruiker toegepas nie.
CLI:
konfigureer terminale rbac-verifikasie wagwoord-leeftyd afdwing ware min-dae 2 maksimum-dae 30 commit
API:
/api/config/rbac/authentication/password-lifetime/
Beperk vorige wagwoordhergebruik
Sonder om die gebruik van vorige wagwoordfrases te voorkom, is die verstryking van wagwoorde grootliks nutteloos aangesien gebruikers eenvoudig die wagwoordfrase kan verander en dit dan terug na die oorspronklike kan verander. NFVIS kontroleer dat die nuwe wagwoord nie dieselfde is as een van die 5 voorheen gebruikte wagwoorde nie. Een uitsondering op hierdie reël is dat die admin-gebruiker die wagwoord na die verstekwagwoord kan verander, selfs al was dit een van die 5 voorheen gebruikte wagwoorde.
Beperk die frekwensie van aanmeldpogings
As 'n afgeleë eweknie toegelaat word om 'n onbeperkte aantal kere aan te meld, kan dit uiteindelik die aanmeldbewyse met brute geweld raai. Aangesien wagfrases dikwels maklik is om te raai, is dit 'n algemene aanval. Deur die tempo waarteen die eweknie kan probeer aanmeld te beperk, voorkom ons hierdie aanval. Ons vermy ook die besteding van die stelselhulpbronne aan die onnodige verifikasie van hierdie brute-force-aanmeldingspogings wat 'n ontkenningsaanval kan veroorsaak. NFVIS dwing 'n 5 minute gebruikerstoesluit af na 10 mislukte aanmeldpogings.
Deaktiveer onaktiewe gebruikersrekeninge
Die monitering van gebruikersaktiwiteit en die deaktivering van ongebruikte of verouderde gebruikersrekeninge help om die stelsel teen insideraanvalle te beveilig. Die ongebruikte rekeninge moet uiteindelik verwyder word. Die admin-gebruiker kan 'n reël afdwing om ongebruikte gebruikerrekeninge as onaktief te merk en die aantal dae opstel waarna 'n ongebruikte gebruikersrekening as onaktief gemerk word. Sodra dit as onaktief gemerk is, kan daardie gebruiker nie by die stelsel aanmeld nie. Om die gebruiker toe te laat om by die stelsel aan te meld, kan die admin gebruiker die gebruikersrekening aktiveer.
Let wel Die onaktiwiteitsperiode en die reël om die onaktiwiteitsperiode na te gaan word nie op die admin gebruiker toegepas nie.

Sekuriteitsoorwegings 6

Veiligheidsoorwegings

Aktivering van 'n onaktiewe gebruikersrekening

Die volgende CLI en API kan gebruik word om die afdwinging van rekeningonaktiwiteit op te stel. CLI:
konfigureer terminale rbac-verifikasie rekening-onaktiwiteit afdwing ware onaktiwiteit-dae 30 commit
API:
/api/config/rbac/authentication/account-inactivity/
Die verstekwaarde vir onaktiwiteitsdae is 35.
Aktivering van 'n onaktiewe gebruikerrekening Die admin gebruiker kan die rekening van 'n onaktiewe gebruiker aktiveer deur die volgende CLI en API te gebruik: CLI:
stel terminale rbac-verifikasie gebruikers gebruiker guest_user aktiveer commit op
API:
/api/operations/rbac/verifikasie/gebruikers/gebruiker/gebruikersnaam/aktiveer

Dwing die instelling van BIOS- en CIMC-wagwoorde af

Tabel 1: Kenmerkgeskiedenistabel

Kenmerknaam

Vrystelling inligting

Dwing instelling van BIOS en CIMC NFVIS 4.7.1 Wagwoorde af

Beskrywing
Hierdie kenmerk dwing die gebruiker af om die verstekwagwoord vir CIMC en BIOS te verander.

Beperkings vir die afdwinging van die instelling van BIOS- en CIMC-wagwoorde
· Hierdie kenmerk word slegs ondersteun op Cisco Catalyst 8200 UCPE en Cisco ENCS 5400 platforms.
· Hierdie kenmerk word slegs ondersteun op 'n nuwe installasie van NFVIS 4.7.1 en later vrystellings. As jy van NFVIS 4.6.1 na NFVIS 4.7.1 opgradeer, word hierdie kenmerk nie ondersteun nie en word jy nie gevra om die BIOS- en CIMS-wagwoorde terug te stel nie, selfs al is die BIOS- en CIMC-wagwoorde nie opgestel nie.

Inligting oor die afdwinging van die instelling van BIOS- en CIMC-wagwoorde
Hierdie kenmerk spreek 'n sekuriteitsgaping aan deur die terugstel van die BIOS- en CIMC-wagwoorde af te dwing na 'n nuwe installering van NFVIS 4.7.1. Die verstek CIMC wagwoord is wagwoord en die verstek BIOS wagwoord is geen wagwoord nie.
Om die sekuriteitsgaping reg te stel, word jy afgedwing om die BIOS- en CIMC-wagwoorde in ENCS 5400 op te stel. Tydens 'n nuwe installering van NFVIS 4.7.1, as die BIOS- en CIMC-wagwoorde nie verander is nie en steeds het

Sekuriteitsoorwegings 7

Konfigurasie Bvamples vir gedwonge terugstelling van BIOS- en CIMC-wagwoorde

Veiligheidsoorwegings

die verstekwagwoorde, dan word jy gevra om beide die BIOS- en CIMC-wagwoorde te verander. As slegs een van hulle herstel vereis, word u gevra om die wagwoord vir slegs daardie komponent terug te stel. Cisco Catalyst 8200 UCPE vereis slegs die BIOS-wagwoord en dus word slegs die BIOS-wagwoordterugstelling gevra, indien dit nie reeds ingestel is nie.
Let wel As jy van enige vorige vrystelling na NFVIS 4.7.1 of later vrystellings opgradeer, kan jy die BIOS- en CIMC-wagwoorde verander deur die gasheeraksie verander-bios-wagwoord nuwe wagwoord of gasheeraksie verander-cimc-wagwoord nuwe wagwoord opdragte te gebruik.
Vir meer inligting oor BIOS- en CIMC-wagwoorde, sien BIOS en CIMC-wagwoord.
Konfigurasie Bvamples vir gedwonge terugstelling van BIOS- en CIMC-wagwoorde
1. Wanneer jy NFVIS 4.7.1 installeer, moet jy eers die verstek admin wagwoord terugstel.
Cisco Network Function Virtualization Infrastructure Software (NFVIS)
NFVIS Weergawe: 99.99.0-1009
Kopiereg (c) 2015-2021 deur Cisco Systems, Inc. Cisco, Cisco Systems en Cisco Systems-logo is geregistreerde handelsmerke van Cisco Systems, Inc. en/of sy affiliasies in die VSA en sekere ander lande.
Die kopiereg op sekere werke wat in hierdie sagteware vervat is, word deur ander derde partye besit en onder derdeparty-lisensie-ooreenkomste gebruik en versprei. Sekere komponente van hierdie sagteware is gelisensieer onder die GNU GPL 2.0, GPL 3.0, LGPL 2.1, LGPL 3.0 en AGPL 3.0.
admin verbind vanaf 10.24.109.102 met ssh op nfvis admin aangemeld met verstek geloofsbriewe Verskaf asseblief 'n wagwoord wat aan die volgende kriteria voldoen:
1.Minstens een kleinletterkarakter 2.Minstens een hoofletterkarakter 3.Minstens een nommer 4.Minstens een spesiale karakter van # _ – * ? 5.Lengte moet tussen 7 en 128 karakters wees Stel asseblief die wagwoord terug: Voer asseblief die wagwoord weer in:
Stel admin wagwoord terug
2. Op Cisco Catalyst 8200 UCPE en Cisco ENCS 5400 platforms wanneer jy 'n vars installasie van NFVIS 4.7.1 of later vrystellings doen, moet jy die verstek BIOS en CIMC wagwoorde verander. As die BIOS- en CIMC-wagwoorde nie voorheen opgestel is nie, vra die stelsel jou om die BIOS- en CIMC-wagwoorde vir Cisco ENCS 5400 terug te stel en slegs die BIOS-wagwoord vir Cisco Catalyst 8200 UCPE.
Nuwe admin wagwoord is ingestel
Verskaf asseblief die BIOS-wagwoord wat aan die volgende kriteria voldoen: 1. Ten minste een kleinletterkarakter 2. Ten minste een hoofletterkarakter 3. Ten minste een nommer 4. Ten minste een spesiale karakter van #, @ of _ 5. Lengte moet tussen 8 en 20 karakters 6. Moet nie enige van die volgende stringe bevat nie (hooflettergevoelig): bios 7. Eerste karakter kan nie 'n # wees nie

Sekuriteitsoorwegings 8

Veiligheidsoorwegings

Verifieer BIOS- en CIMC-wagwoorde

Stel asseblief die BIOS-wagwoord terug: Voer asseblief die BIOS-wagwoord weer in: Verskaf asseblief die CIMC-wagwoord wat aan die volgende kriteria voldoen:
1. Ten minste een kleinletterkarakter 2. Ten minste een hoofletterkarakter 3. Ten minste een nommer 4. Ten minste een spesiale karakter van #, @ of _ 5. Lengte moet tussen 8 en 20 karakters wees 6. Moet nie enige van die volgende stringe (hooflettersensitief): admin Stel asseblief die CIMC-wagwoord terug: Voer asseblief die CIMC-wagwoord weer in:

Verifieer BIOS- en CIMC-wagwoorde
Om te verifieer of die BIOS- en CIMC-wagwoorde suksesvol verander is, gebruik die show log nfvis_config.log | sluit BIOS in of wys log nfvis_config.log | sluit CIMC-opdragte in:

nfvis# wys log nfvis_config.log | sluit BIOS in

2021-11-16 15:24:40,102 INFO

[gasheeraksie:/stelsel/instellings] [] BIOS-wagwoordverandering

suksesvol is

Jy kan ook die nfvis_config.log aflaai file en verifieer of die wagwoorde suksesvol teruggestel is.

Integrasie met eksterne AAA-bedieners
Gebruikers meld aan by NFVIS deur ssh of die Web UI. In beide gevalle moet gebruikers geverifieer word. Dit wil sê, 'n gebruiker moet wagwoordbewyse voorlê om toegang te verkry.
Sodra 'n gebruiker geverifieer is, moet alle bewerkings wat deur daardie gebruiker uitgevoer word, gemagtig word. Dit wil sê, sekere gebruikers mag toegelaat word om sekere take uit te voer, terwyl ander nie. Dit word magtiging genoem.
Dit word aanbeveel dat 'n gesentraliseerde AAA-bediener ontplooi word om per gebruiker, AAA-gebaseerde aanmeldverifikasie vir NFVIS-toegang af te dwing. NFVIS ondersteun RADIUS- en TACACS-protokolle om netwerktoegang te bemiddel. Op die AAA-bediener moet slegs minimum toegangsregte aan geverifieerde gebruikers toegestaan ​​word volgens hul spesifieke toegangsvereistes. Dit verminder die blootstelling aan beide kwaadwillige en onopsetlike sekuriteitsinsidente.
Vir meer inligting oor eksterne verifikasie, sien RADIUS konfigureer en 'n TACACS+-bediener konfigureer.

Verifikasiekas vir eksterne verifikasiebediener

Kenmerknaam

Vrystelling inligting

Verifikasiekas vir eksterne NFVIS 4.5.1 Verifikasiebediener

Beskrywing
Hierdie kenmerk ondersteun TACACS-verifikasie deur OTP op NFVIS-portaal.

Die NFVIS-portaal gebruik dieselfde eenmalige wagwoord (OTP) vir alle API-oproepe na die aanvanklike verifikasie. Die API-oproepe misluk sodra die OTP verval. Hierdie kenmerk ondersteun TACACS OTP-verifikasie met die NFVIS-portaal.
Nadat jy suksesvol deur die TACACS-bediener geverifieer het deur 'n OTP te gebruik, skep NFVIS 'n hash-inskrywing deur die gebruikernaam en die OTP te gebruik en stoor hierdie hash-waarde plaaslik. Hierdie plaaslik gestoor hash-waarde het

Sekuriteitsoorwegings 9

Rolgebaseerde toegangsbeheer

Veiligheidsoorwegings

'n vervaltyd stamp daarmee geassosieer. Die tyd stamp het dieselfde waarde as die SSH-sessie ledige uittelwaarde wat 15 minute is. Al die daaropvolgende stawingversoeke met dieselfde gebruikersnaam word eers teen hierdie plaaslike hash-waarde geverifieer. As die verifikasie met die plaaslike hash misluk, verifieer NFVIS hierdie versoek met TACACS-bediener en skep 'n nuwe hash-inskrywing wanneer die verifikasie suksesvol is. As 'n hash-inskrywing reeds bestaan, sy tyd stamp word na 15 minute teruggestel.
As jy van die TACACS-bediener verwyder word nadat jy suksesvol by die portaal aangemeld het, kan jy voortgaan om die portaal te gebruik totdat die hash-inskrywing in NFVIS verval.
Wanneer jy uitdruklik by die NFVIS-portaal afmeld of afgemeld word weens ledige tyd, roep die portaal 'n nuwe API om NFVIS-backend in kennis te stel om die hash-inskrywing te spoel. Die verifikasiekas en al sy inskrywings word uitgevee na NFVIS-herlaai, fabrieksterugstelling of opgradering.

Rolgebaseerde toegangsbeheer

Die beperking van netwerktoegang is belangrik vir organisasies wat baie werknemers het, kontrakteurs in diens neem of toegang tot derde partye toelaat, soos kliënte en verskaffers. In so 'n scenario is dit moeilik om netwerktoegang effektief te monitor. In plaas daarvan is dit beter om te beheer wat toeganklik is, om die sensitiewe data en kritieke toepassings te beveilig.
Rolgebaseerde toegangsbeheer (RBAC) is 'n metode om netwerktoegang te beperk gebaseer op die rolle van individuele gebruikers binne 'n onderneming. RBAC laat gebruikers toegang tot net die inligting wat hulle nodig het, en verhoed dat hulle toegang tot inligting kry wat nie op hulle betrekking het nie.
'n Werknemer se rol in die onderneming moet gebruik word om die toestemmings wat verleen word te bepaal, om te verseker dat werknemers met laer voorregte nie toegang tot sensitiewe inligting kan kry of kritieke take kan verrig nie.
Die volgende gebruikersrolle en -voorregte word in NFVIS gedefinieer

Gebruikersrol

Voorreg

Administrateurs

Kan alle beskikbare kenmerke opstel en alle take uitvoer, insluitend die verandering van gebruikersrolle. Die administrateur kan nie basiese infrastruktuur uitvee wat fundamenteel vir NFVIS is nie. Die Admin gebruiker se rol kan nie verander word nie; dit is altyd “administrateurs”.

Operateurs

Kan 'n VM begin en stop, en view alle inligting.

Ouditeure

Hulle is die minste bevoorregte gebruikers. Hulle het Leesalleen-toestemming en kan dus geen konfigurasie verander nie.

Voordele van RBAC
Daar is 'n aantal voordele verbonde aan die gebruik van RBAC om onnodige netwerktoegang te beperk op grond van mense se rolle binne 'n organisasie, insluitend:
· Verbetering van bedryfsdoeltreffendheid.
Deur vooraf gedefinieerde rolle in RBAC te hê, is dit maklik om nuwe gebruikers met die regte voorregte in te sluit of rolle van bestaande gebruikers te verander. Dit verminder ook die potensiaal vir foute wanneer gebruikerstoestemmings toegeken word.
· Verbetering van voldoening.

Sekuriteitsoorwegings 10

Veiligheidsoorwegings

Rolgebaseerde toegangsbeheer

Elke organisasie moet voldoen aan plaaslike, staats- en federale regulasies. Maatskappye verkies oor die algemeen om RBAC-stelsels te implementeer om aan die regulatoriese en statutêre vereistes vir vertroulikheid en privaatheid te voldoen omdat bestuurders en IT-departemente meer effektief kan bestuur hoe toegang tot die data verkry en gebruik word. Dit is veral belangrik vir finansiële instellings en gesondheidsorgmaatskappye wat sensitiewe data bestuur.
· Vermindering van koste. Deur nie gebruikerstoegang tot sekere prosesse en toepassings toe te laat nie, kan maatskappye hulpbronne soos netwerkbandwydte, geheue en berging op 'n koste-effektiewe wyse bespaar of gebruik.
· Verminderde risiko van oortredings en datalek. Die implementering van RBAC beteken om toegang tot sensitiewe inligting te beperk, en sodoende die potensiaal vir data-oortredings of data-lekkasie te verminder.
Beste praktyke vir rolgebaseerde toegangsbeheerimplementerings · Bepaal as administrateur die lys gebruikers en wys die gebruikers aan die voorafbepaalde rolle toe. Byvoorbeeldample, kan die gebruiker “netwerkadmin” geskep en by die gebruikersgroep “administrateurs” gevoeg word.
stel terminale rbac-verifikasie gebruikers skep-gebruikernaam netwerkadmin wagwoord Test1_pass rol administrateurs commit
Let wel Die gebruikergroepe of rolle word deur die stelsel geskep. Jy kan nie 'n gebruikersgroep skep of wysig nie. Om die wagwoord te verander, gebruik die rbac-verifikasie gebruikers gebruiker verander-wagwoord opdrag in globale konfigurasie af. Om die gebruikerrol te verander, gebruik die rbac-verifikasie gebruikers gebruiker verander-rol opdrag in globale konfigurasie af.
· Beëindig rekeninge vir gebruikers wat nie meer toegang benodig nie.
konfigureer terminale rbac-verifikasie gebruikers verwyder-gebruikersnaam toets1
· Voer gereeld oudits uit om die rolle te evalueer, die werknemers wat aan hulle toegewys is en die toegang wat vir elke rol toegelaat word. As daar gevind word dat 'n gebruiker onnodige toegang tot 'n sekere stelsel het, verander die gebruiker se rol.
Sien Gebruikers, Rolle en Verifikasie vir meer besonderhede
Granulêre rolgebaseerde toegangsbeheer Vanaf NFVIS 4.7.1 word die granulêre rolgebaseerde toegangsbeheerfunksie bekendgestel. Hierdie kenmerk voeg 'n nuwe hulpbrongroepbeleid by wat die VM en VNF bestuur en laat jou toe om gebruikers aan 'n groep toe te wys om VNF-toegang te beheer, tydens VNF-ontplooiing. Vir meer inligting, sien Granular Rol-Based Access Control.

Sekuriteitsoorwegings 11

Beperk Toesteltoeganklikheid

Veiligheidsoorwegings

Beperk Toesteltoeganklikheid
Gebruikers is herhaaldelik onverhoeds betrap deur aanvalle op kenmerke wat hulle nie beskerm het nie omdat hulle nie geweet het dat daardie kenmerke geaktiveer is nie. Ongebruikte dienste is geneig om met verstekkonfigurasies gelaat te word wat nie altyd veilig is nie. Hierdie dienste kan ook verstekwagwoorde gebruik. Sommige dienste kan 'n aanvaller maklike toegang gee tot inligting oor wat die bediener loop of hoe die netwerk opgestel is. Die volgende afdelings beskryf hoe NFVIS sulke sekuriteitsrisiko's vermy:

Aanvalvektorvermindering
Enige stuk sagteware kan moontlik sekuriteitskwesbaarhede bevat. Meer sagteware beteken meer weë vir aanval. Selfs al is daar geen publiek bekende kwesbaarhede ten tyde van insluiting nie, sal kwesbaarhede waarskynlik in die toekoms ontdek of geopenbaar word. Om sulke scenario's te vermy, word slegs die sagtewarepakkette wat noodsaaklik is vir die NFVIS-funksionaliteit geïnstalleer. Dit help om sagteware-kwesbaarhede te beperk, hulpbronverbruik te verminder en ekstra werk te verminder wanneer probleme met daardie pakkette gevind word. Alle derdeparty-sagteware wat in NFVIS ingesluit is, is by 'n sentrale databasis in Cisco geregistreer sodat Cisco in staat is om 'n georganiseerde reaksie op maatskappyvlak (wettig, sekuriteit, ens.) uit te voer. Sagtewarepakkette word van tyd tot tyd in elke vrystelling reggemaak vir bekende algemene kwesbaarhede en blootstellings (CVE's).

Aktiveer slegs noodsaaklike poorte by verstek

Slegs die dienste wat absoluut noodsaaklik is om NFVIS op te stel en te bestuur, is by verstek beskikbaar. Dit verwyder die gebruikerpoging wat nodig is om firewalls op te stel en toegang tot onnodige dienste te weier. Die enigste dienste wat by verstek geaktiveer is, word hieronder gelys saam met die poorte wat hulle oopmaak.

Maak Port oop

Diens

Beskrywing

22 / TCP

SSH

Secure Socket Shell vir afgeleë opdragreëltoegang tot NFVIS

80 / TCP

HTTP

Hiperteksoordragprotokol vir die NFVIS-portaaltoegang. Alle HTTP-verkeer wat deur NFVIS ontvang word, word herlei na poort 443 vir HTTPS

443 / TCP

HTTPS

Hypertext Transfer Protocol Veilig vir veilige NFVIS-portaaltoegang

830 / TCP

NETCONF-ssh

Poort oopgemaak vir die Network Configuration Protocol (NETCONF) oor SSH. NETCONF is 'n protokol wat gebruik word vir outomatiese konfigurasie van NFVIS en vir die ontvangs van asinchroniese gebeurteniskennisgewings vanaf NFVIS.

161/UDP

SNMP

Eenvoudige netwerkbestuurprotokol (SNMP). Word deur NFVIS gebruik om met afgeleë netwerkmonitering-toepassings te kommunikeer. Vir meer inligting, sien Inleiding oor SNMP

Sekuriteitsoorwegings 12

Veiligheidsoorwegings

Beperk toegang tot gemagtigde netwerke vir gemagtigde dienste

Beperk toegang tot gemagtigde netwerke vir gemagtigde dienste

Slegs gemagtigde skeppers moet toegelaat word om selfs toegang tot toestelbestuur te probeer, en toegang moet slegs wees tot die dienste wat hulle gemagtig is om te gebruik. NFVIS kan so gekonfigureer word dat toegang beperk word tot bekende, betroubare bronne en verwagte bestuursverkeer profiles. Dit verminder die risiko van ongemagtigde toegang en die blootstelling aan ander aanvalle, soos brute force, woordeboek of DoS-aanvalle.
Om die NFVIS-bestuurskoppelvlakke te beskerm teen onnodige en potensieel skadelike verkeer, kan 'n admin gebruiker toegangsbeheerlyste (ACL's) skep vir die netwerkverkeer wat ontvang word. Hierdie ACL's spesifiseer die bron IP-adresse/netwerke waaruit die verkeer afkomstig is, en die tipe verkeer wat toegelaat of afgekeur word vanaf hierdie bronne. Hierdie IP-verkeerfilters word op elke bestuurskoppelvlak op NFVIS toegepas. Die volgende parameters is opgestel in 'n IP-ontvangtoegangsbeheerlys (ip-receive-acl)

Parameter

Waarde

Beskrywing

Bronnetwerk/Netmasker

Netwerk/netmasker. Byvoorbeeldample: 0.0.0.0/0
172.39.162.0/24

Hierdie veld spesifiseer die IP-adres/netwerk waaruit die verkeer afkomstig is

Diens Aksie

https icmp netconf scpd snmp ssh aanvaar druppelverwerping

Tipe verkeer vanaf die gespesifiseerde bron.
Optrede wat geneem moet word op die verkeer vanaf die bronnetwerk. Met aanvaar sal nuwe verbindingspogings toegestaan ​​word. Met verwerping sal verbindingspogings nie aanvaar word nie. As die reël vir 'n TCP-gebaseerde diens soos HTTPS, NETCONF, SCP, SSH is, sal die bron 'n TCP-terugstelling (RST) pakkie kry. Vir nie-TCP-reëls soos SNMP en ICMP, sal die pakkie weggelaat word. Met drop, sal alle pakkies onmiddellik laat val word, daar is geen inligting na die bron gestuur nie.

Sekuriteitsoorwegings 13

Bevoorregte ontfouttoegang

Veiligheidsoorwegings

Parameter prioriteit

Waarde 'n Numeriese waarde

Beskrywing
Die prioriteit word gebruik om 'n bevel op die reëls af te dwing. Reëls met 'n hoër numeriese waarde vir prioriteit sal verder af in die ketting bygevoeg word. As jy seker wil maak dat 'n reël na 'n ander een bygevoeg sal word, gebruik 'n lae prioriteit nommer vir die eerste en 'n hoër prioriteit nommer vir die volgende.

Die volgende aample konfigurasies illustreer 'n paar scenario's wat aangepas kan word vir spesifieke gebruiksgevalle.
Die opstel van die IP-ontvangs ACL
Hoe meer beperkend 'n ACL is, hoe meer beperk is die blootstelling aan ongemagtigde toegangspogings. 'n Meer beperkende ACL kan egter 'n bestuursbokoste skep, en kan toeganklikheid beïnvloed om foutsporing uit te voer. Gevolglik is daar 'n balans wat oorweeg moet word. Een kompromie is om toegang slegs tot interne korporatiewe IP-adresse te beperk. Elke kliënt moet die implementering van ACL's evalueer met betrekking tot hul eie sekuriteitsbeleid, risiko's, blootstelling en aanvaarding daarvan.
Verwerp ssh-verkeer vanaf 'n subnet:

nfvis(config)# stelselinstellings ip-receive-acl 171.70.63.0/24 diens ssh aksie verwerp prioriteit 1

Verwyder ACL's:
Wanneer 'n inskrywing van ip-receive-acl uitgevee word, word alle konfigurasies na daardie bron uitgevee aangesien die bron-IP-adres die sleutel is. Om net een diens uit te vee, stel ander dienste weer op.

nfvis(config)# geen stelselinstellings ip-receive-acl 171.70.63.0/24
Vir meer besonderhede sien, Konfigureer die IP-ontvangs-ACL
Bevoorregte ontfouttoegang
Die supergebruikerrekening op NFVIS is by verstek gedeaktiveer om alle onbeperkte, potensieel nadelige, stelselwye veranderinge te voorkom en NFVIS stel nie die stelseldop aan die gebruiker bloot nie.
Vir sommige probleme wat moeilik is om op die NFVIS-stelsel te ontfout, kan die Cisco Technical Assistance Centre-span (TAC) of ontwikkelingspan dalk doptoegang tot die kliënt se NFVIS benodig. NFVIS het 'n veilige ontsluitinfrastruktuur om te verseker dat bevoorregte ontfoutingstoegang tot 'n toestel in die veld beperk word tot gemagtigde Cisco-werknemers. Om veilige toegang tot die Linux-dop vir hierdie soort interaktiewe ontfouting te verkry, word 'n uitdaging-reaksie-verifikasiemeganisme gebruik tussen NFVIS en die Interaktiewe ontfoutingsbediener wat deur Cisco onderhou word. Die administrateur-gebruiker se wagwoord word ook bykomend tot die uitdaging-reaksie-inskrywing vereis om te verseker dat toegang tot die toestel verkry word met die kliënt se toestemming.
Stappe om toegang tot die dop vir interaktiewe ontfouting te verkry:
1. 'n Admin gebruiker begin hierdie prosedure deur hierdie versteekte opdrag te gebruik.

nfvis# stelsel dop-toegang

Sekuriteitsoorwegings 14

Veiligheidsoorwegings

Veilige koppelvlakke

2. Die skerm sal 'n uitdagingstring wys, bvample:
Uitdagingstring (kopieer asseblief alles uitsluitlik tussen die sterretjies):
******************************************************************************** SPH//wkAAABORlZJU0VOQ1M1NDA4L0s5AQAAABt+dcx+hB0V06r9RkdMMjEzNTgw RlHq7BxeAAA= DONE. ********************************************************************************
3. Die Cisco-lid voer die uitdagingstring in op 'n interaktiewe ontfoutbediener wat deur Cisco in stand gehou word. Hierdie bediener verifieer dat die Cisco-gebruiker gemagtig is om NFVIS te ontfout deur die dop te gebruik, en gee dan 'n antwoordstring terug.
4. Tik die antwoordstring op die skerm onder hierdie prompt in: Voer jou antwoord in wanneer gereed:
5. Wanneer gevra word, moet die kliënt die admin wagwoord invoer. 6. Jy kry dop-toegang as die wagwoord geldig is. 7. Ontwikkeling- of TAC-span gebruik die dop om voort te gaan met die ontfouting. 8. Om doptoegang te verlaat, tik Exit.
Veilige koppelvlakke
NFVIS-bestuurtoegang word toegelaat deur gebruik te maak van die koppelvlakke wat in die diagram getoon word. Die volgende afdelings beskryf die beste praktyke vir sekuriteit vir hierdie koppelvlakke na NFVIS.

Konsole SSH

Die konsolepoort is 'n asynchrone reekspoort wat jou toelaat om aan die NFVIS CLI te koppel vir aanvanklike konfigurasie. 'n Gebruiker kan toegang tot die konsole verkry met óf fisiese toegang tot die NFVIS óf afstandtoegang deur die gebruik van 'n terminale bediener. As konsolepoorttoegang via 'n terminaalbediener vereis word, stel toegangslyste op die terminaalbediener op om toegang slegs vanaf die vereiste bronadresse toe te laat.
Gebruikers kan toegang tot die NFVIS CLI kry deur SSH te gebruik as 'n veilige manier van aanmelding op afstand. Die integriteit en vertroulikheid van NFVIS-bestuursverkeer is noodsaaklik vir die sekuriteit van die geadministreerde netwerk aangesien administrasieprotokolle gereeld inligting bevat wat gebruik kan word om die netwerk binne te dring of te ontwrig.

Sekuriteitsoorwegings 15

CLI Sessie uitteltyd

Veiligheidsoorwegings

NFVIS gebruik SSH weergawe 2, wat Cisco en die Internet se de facto standaardprotokol vir interaktiewe aanmeldings is en ondersteun sterk enkripsie, hash en sleuteluitruilalgoritmes wat aanbeveel word deur die Sekuriteit- en Trustorganisasie binne Cisco.

CLI Sessie uitteltyd
Deur via SSH aan te meld, vestig 'n gebruiker 'n sessie met NFVIS. Terwyl die gebruiker aangemeld is, as die gebruiker die aangemelde sessie onbewaak laat, kan dit die netwerk aan 'n sekuriteitsrisiko blootstel. Sessie-sekuriteit beperk die risiko van interne aanvalle, soos een gebruiker wat probeer om 'n ander gebruiker se sessie te gebruik.
Om hierdie risiko te verminder, vertraag NFVIS CLI-sessies na 15 minute se onaktiwiteit. Wanneer die sessie-time-out bereik is, word die gebruiker outomaties afgemeld.

NETCONF

Die Network Configuration Protocol (NETCONF) is 'n netwerkbestuurprotokol wat deur die IETF ontwikkel en gestandaardiseer is vir die outomatiese opstelling van netwerktoestelle.
Die NETCONF-protokol gebruik 'n Extensible Markup Language (XML)-gebaseerde data-kodering vir die konfigurasiedata sowel as die protokolboodskappe. Die protokolboodskappe word bo-op 'n veilige vervoerprotokol uitgeruil.
NETCONF laat NFVIS toe om 'n XML-gebaseerde API bloot te stel wat die netwerkoperateur kan gebruik om konfigurasiedata en gebeurteniskennisgewings veilig oor SSH te stel en te kry.
Vir meer inligting, sien NETCONF Gebeurteniskennisgewings.

REST API

NFVIS kan gekonfigureer word met behulp van RESTful API oor HTTPS. Die REST API laat die versoekende stelsels toe om toegang tot die NFVIS-konfigurasie te verkry en te manipuleer deur 'n eenvormige en voorafbepaalde stel staatlose bedrywighede te gebruik. Besonderhede oor al die REST API's kan gevind word in die NFVIS API Verwysingsgids.
Wanneer die gebruiker 'n REST API uitreik, word 'n sessie met NFVIS gevestig. Om risiko's wat verband hou met diensweieraanvalle te beperk, beperk NFVIS die totale aantal gelyktydige REST-sessies tot 100.

NFVIS Web Portaal
Die NFVIS-portaal is 'n web-gebaseerde grafiese gebruikerskoppelvlak wat inligting oor NFVIS vertoon. Die portaal bied die gebruiker 'n maklike manier om NFVIS oor HTTPS op te stel en te monitor sonder om die NFVIS CLI en API te ken.

Sessiebestuur
Die staatlose aard van HTTP en HTTPS vereis 'n metode om gebruikers uniek op te spoor deur die gebruik van unieke sessie-ID's en koekies.
NFVIS enkripteer die gebruiker se sessie. Die AES-256-CBC-syfer word gebruik om die sessie-inhoud te enkripteer met 'n HMAC-SHA-256-verifikasie tag. 'n Ewekansige 128-bis initialiseringsvektor word vir elke enkripsiebewerking gegenereer.
'n Ouditrekord word begin wanneer 'n portaalsessie geskep word. Sessie-inligting word uitgevee wanneer die gebruiker afmeld of wanneer die sessie uittel.
Die verstek ledige uitteltyd vir portaalsessies is 15 minute. Dit kan egter vir die huidige sessie op 'n waarde tussen 5 en 60 minute op die Instellings-bladsy gekonfigureer word. Outo-afmeld sal hierna begin word

Sekuriteitsoorwegings 16

Veiligheidsoorwegings

HTTPS

HTTPS

tydperk. Veelvuldige sessies word nie in 'n enkele blaaier toegelaat nie. Die maksimum aantal gelyktydige sessies is op 30 gestel. Die NFVIS-portaal gebruik koekies om data met die gebruiker te assosieer. Dit gebruik die volgende koekie-eienskappe vir verbeterde sekuriteit:
· kortstondig om te verseker dat die koekie verval wanneer die blaaier gesluit is · httpSlegs om die koekie ontoeganklik te maak vanaf JavaScript · secureProxy om te verseker dat die koekie slegs oor SSL gestuur kan word.
Selfs na verifikasie is aanvalle soos Cross-Site Request Forgery (CSRF) moontlik. In hierdie scenario kan 'n eindgebruiker per ongeluk ongewenste handelinge op 'n web toepassing waarin hulle tans geverifieer is. Om dit te voorkom, gebruik NFVIS CSRF-tokens om elke REST API wat tydens elke sessie opgeroep word, te bekragtig.
URL Herleiding In tipiese web bedieners, wanneer 'n bladsy nie gevind word op die web bediener, die gebruiker kry 'n 404-boodskap; vir bladsye wat bestaan, kry hulle 'n aanmeldbladsy. Die sekuriteitsimpak hiervan is dat 'n aanvaller 'n brute force-skandering kan uitvoer en maklik kan opspoor watter bladsye en vouers bestaan. Om dit op NFVIS te voorkom, bestaan ​​alles nie URLse voorvoegsel met die toestel-IP word herlei na die portaalaanmeldbladsy met 'n 301-statusresponskode. Dit beteken dat ongeag die URL deur 'n aanvaller versoek, sal hulle altyd die aanmeldbladsy kry om hulself te verifieer. Alle HTTP-bedienerversoeke word na HTTPS herlei en het die volgende opskrifte opgestel:
· X-Inhoud-tipe-opsies · X-XSS-beskerming · Inhoud-sekuriteit-beleid · X-raam-opsies · Streng-vervoer-sekuriteit · Kasbeheer
Deaktiveer die portaal Die NFVIS-portaaltoegang is by verstek geaktiveer. As jy nie van plan is om die portaal te gebruik nie, word dit aanbeveel om portaaltoegang te deaktiveer deur hierdie opdrag te gebruik:
Stel terminaal Stelselportaaltoegang gedeaktiveer toe
Al die HTTPS-data na en van NFVIS gebruik Transport Layer Security (TLS) om oor die netwerk te kommunikeer. TLS is die opvolger van Secure Socket Layer (SSL).

Sekuriteitsoorwegings 17

HTTPS

Veiligheidsoorwegings
Die TLS-handdruk behels verifikasie waartydens die kliënt die bediener se SSL-sertifikaat verifieer met die sertifikaatowerheid wat dit uitgereik het. Dit bevestig dat die bediener is wie dit sê dit is, en dat die kliënt interaksie het met die eienaar van die domein. By verstek gebruik NFVIS 'n selfondertekende sertifikaat om sy identiteit aan sy kliënte te bewys. Hierdie sertifikaat het 'n 2048-bis publieke sleutel om die sekuriteit van die TLS-enkripsie te verhoog, aangesien die enkripsiesterkte direk verband hou met die sleutelgrootte.
Sertifikaatbestuur NFVIS genereer 'n selfondertekende SSL-sertifikaat wanneer dit eers geïnstalleer word. Dit is 'n beste praktyk vir sekuriteit om hierdie sertifikaat te vervang met 'n geldige sertifikaat wat deur 'n voldoenende sertifikaatowerheid (CA) onderteken is. Gebruik die volgende stappe om die verstek self-ondertekende sertifikaat te vervang: 1. Genereer 'n sertifikaatondertekeningversoek (CSR) op NFVIS.
'n Versoek om sertifikaatondertekening (CSR) is 'n file met 'n blok geënkodeerde teks wat aan 'n sertifikaatowerheid gegee word wanneer aansoek gedoen word vir 'n SSL-sertifikaat. Hierdie file bevat inligting wat in die sertifikaat ingesluit moet word, soos die organisasie se naam, algemene naam (domeinnaam), ligging en land. Die file bevat ook die publieke sleutel wat in die sertifikaat ingesluit moet word. NFVIS gebruik 'n 2048-bis publieke sleutel aangesien enkripsiesterkte hoër is met 'n hoër sleutelgrootte. Om 'n CSR op NFVIS te genereer, voer die volgende opdrag uit:
nfvis# stelsel sertifikaat ondertekening-versoek [gewone naam land-kode ligging organisasie organisasie-eenheid-naam staat] Die CSR file word gestoor as /data/intdatastore/download/nfvis.csr. . 2. Kry 'n SSL-sertifikaat van 'n CA deur die CSR te gebruik. Gebruik die scp-opdrag vanaf 'n eksterne gasheer om die sertifikaatondertekeningversoek af te laai.
[myhost:/tmp] > scp -P 22222 admin@ :/data/intdatastore/download/nfvis.csrfile-naam>
Kontak 'n sertifikaatowerheid om 'n nuwe SSL-bedienersertifikaat uit te reik deur hierdie CSR te gebruik. 3. Installeer die CA Signed Certificate.
Gebruik die scp-opdrag vanaf 'n eksterne bediener om die sertifikaat op te laai file in NFVIS na die data/intdatastore/uploads/ gids.
[myhost:/tmp] > scp -P 22222 file> admin@ :/data/intdatastore/oplaaie
Installeer die sertifikaat in NFVIS deur die volgende opdrag te gebruik.
nfvis# stelselsertifikaat installasie-sert pad file:///data/intdatastore/uploads/<certificate file>
4. Skakel oor na die gebruik van die CA Signed Certificate. Gebruik die volgende opdrag om die CA-getekende sertifikaat te begin gebruik in plaas van die verstek self-ondertekende sertifikaat.

Sekuriteitsoorwegings 18

Veiligheidsoorwegings

SNMP Toegang

nfvis(config)# stelselsertifikaat gebruik-sert sertifikaat-tipe ca-onderteken

SNMP Toegang

Simple Network Management Protocol (SNMP) is 'n internetstandaardprotokol vir die versameling en organisering van inligting oor bestuurde toestelle op IP-netwerke, en om daardie inligting te wysig om toestelgedrag te verander.
Drie belangrike weergawes van SNMP is ontwikkel. NFVIS ondersteun SNMP weergawe 1, weergawe 2c en weergawe 3. SNMP weergawes 1 en 2 gebruik gemeenskapstringe vir verifikasie, en dit word in gewone teks gestuur. Dit is dus 'n beste praktyk vir sekuriteit om eerder SNMP v3 te gebruik.
SNMPv3 bied veilige toegang tot toestelle deur drie aspekte te gebruik: – gebruikers, verifikasie en enkripsie. SNMPv3 gebruik die USM (User-based Security Module) vir die beheer van toegang tot inligting wat via SNMP beskikbaar is. Die SNMP v3-gebruiker is opgestel met 'n verifikasietipe, 'n privaatheidstipe sowel as 'n wagwoordfrase. Alle gebruikers wat 'n groep deel, gebruik dieselfde SNMP-weergawe, maar die spesifieke sekuriteitsvlakinstellings (wagwoord, enkripsietipe, ens.) word per gebruiker gespesifiseer.
Die volgende tabel som die sekuriteitsopsies binne SNMP op

Model

Vlak

Stawing

Ensipsie

Uitkoms

v1

noAuthNoPriv

Gemeenskapstring nr

Gebruik 'n gemeenskap

snaar wedstryd vir

verifikasie.

v2c

noAuthNoPriv

Gemeenskapstring nr

Gebruik 'n gemeenskapstringpassing vir stawing.

v3

noAuthNoPriv

Gebruikersnaam

Nee

Gebruik 'n gebruikersnaam

wedstryd vir

verifikasie.

v3

authNoPriv

Boodskapsamevatting 5 No

Verskaf

(MD5)

verifikasie gebaseer

or

op die HMAC-MD5-96 of

Veilige Hash

HMAC-SHA-96

Algoritme (SHA)

algoritmes.

Sekuriteitsoorwegings 19

Regskennisgewingsbaniere

Veiligheidsoorwegings

Model v3

Vlak autPriv

Stawing MD5 of SHA

Ensipsie

Uitkoms

Data-enkripsie verskaf

Standaard (DES) of verifikasie gebaseer

Gevorderd

op die

Enkripsie Standaard HMAC-MD5-96 of

(AES)

HMAC-SHA-96

algoritmes.

Verskaf DES Cipher-algoritme in Cipher Block Chaining Mode (CBC-DES)

or

AES-enkripsie-algoritme wat in Cipher-terugvoermodus (CFB) gebruik word, met 'n 128-bis-sleutelgrootte (CFB128-AES-128)

Sedert die aanvaarding daarvan deur NIST, het AES die dominante enkripsie-algoritme in die hele bedryf geword. Om die industrie se migrasie weg van MD5 en na SHA te volg, is dit 'n beste sekuriteitspraktyk om die SNMP v3-verifikasieprotokol as SHA en privaatheidsprotokol as AES op te stel.
Vir meer besonderhede oor SNMP, sien Inleiding oor SNMP

Regskennisgewingsbaniere
Dit word aanbeveel dat 'n wettige kennisgewingbanier op alle interaktiewe sessies teenwoordig is om te verseker dat gebruikers in kennis gestel word van die sekuriteitsbeleid wat afgedwing word en waaraan hulle onderworpe is. In sommige jurisdiksies is siviele en/of kriminele vervolging van 'n aanvaller wat by 'n stelsel inbreek makliker, of selfs nodig, as 'n wettige kennisgewingbanier aangebied word, wat ongemagtigde gebruikers inlig dat hul gebruik in werklikheid ongemagtig is. In sommige jurisdiksies kan dit ook verbied word om die aktiwiteit van 'n ongemagtigde gebruiker te monitor, tensy hulle in kennis gestel is van die voorneme om dit te doen.
Wetlike kennisgewingvereistes is kompleks en verskil in elke jurisdiksie en situasie. Selfs binne jurisdiksies verskil regsmenings. Bespreek hierdie kwessie met jou eie regsadviseur om te verseker dat die kennisgewingbanier voldoen aan maatskappy-, plaaslike en internasionale wetlike vereistes. Dit is dikwels van kritieke belang om toepaslike optrede te verseker in die geval van 'n sekuriteitskending. In samewerking met die maatskappy se regsadviseur, sluit verklarings in wat in 'n regskennisgewingsbanier ingesluit kan word:
· Kennisgewing dat die stelseltoegang en -gebruik slegs deur spesifiek gemagtigde personeel toegelaat word, en dalk inligting oor wie gebruik mag magtig.
· Kennisgewing dat ongemagtigde toegang en gebruik van die stelsel onwettig is, en kan onderhewig wees aan siviele en/of kriminele strawwe.
· Kennisgewing dat toegang en gebruik van die stelsel sonder verdere kennisgewing aangeteken of gemonitor kan word, en die gevolglike logs kan as bewyse in die hof gebruik word.
· Bykomende spesifieke kennisgewings wat deur spesifieke plaaslike wette vereis word.

Sekuriteitsoorwegings 20

Veiligheidsoorwegings

Fabrieksverstekterugstelling

Van 'n sekuriteit eerder as 'n wetlike punt van view, moet 'n wettige kennisgewingbanier nie enige spesifieke inligting oor die toestel bevat nie, soos sy naam, model, sagteware, ligging, operateur of eienaar, want hierdie soort inligting kan nuttig wees vir 'n aanvaller.
Die volgende is asample wettige kennisgewing banier wat vertoon kan word voor aanmelding:
ONGEMAGTIGDE TOEGANG TOT HIERDIE TOESTEL IS VERBOD Jy moet eksplisiete, gemagtigde toestemming hê om toegang tot hierdie toestel te verkry of op te stel. Ongemagtigde pogings en aksies om toegang te verkry of te gebruik
hierdie stelsel kan siviele en/of kriminele strawwe tot gevolg hê. Alle aktiwiteite wat op hierdie toestel uitgevoer word, word aangeteken en gemonitor

Nota Bied 'n regskennisgewingsbanier aan wat deur die maatskappy se regsadviseur goedgekeur is.
NFVIS laat die konfigurasie van 'n banier en Boodskap van die Dag (MOTD) toe. Die banier word vertoon voordat die gebruiker aanmeld. Sodra die gebruiker by NFVIS aanmeld, verskaf 'n stelselgedefinieerde banier kopiereginligting oor NFVIS, en die boodskap-van-die-dag (MOTD), indien opgestel, sal verskyn, gevolg deur die opdraglynprompt of portaal view, afhangende van die aanmeldmetode.
Dit word aanbeveel dat 'n aantekenbanier geïmplementeer word om te verseker dat 'n wettige kennisgewingbanier op al die toestelbestuurtoegangsessies aangebied word voordat 'n aanmeldaanvraag aangebied word. Gebruik hierdie opdrag om die banier en MOTD op te stel.
nfvis(config)# banier-motd banier motd
Vir meer inligting oor die banieropdrag, sien Konfigureer banier, Boodskap van die dag en Stelseltyd.

Fabrieksverstekterugstelling
Fabrieksterugstelling verwyder al die kliëntspesifieke data wat sedert die versending daarvan by die toestel gevoeg is. Die data wat uitgevee is, sluit konfigurasies, log in files, VM-beelde, verbindingsinligting en gebruikersaanmeldbewyse.
Dit bied een opdrag om die toestel terug te stel na fabrieksoorspronklike instellings, en is nuttig in die volgende scenario's:
· Return Material Authorization (RMA) vir 'n toestel – As jy 'n toestel aan Cisco moet terugbesorg vir RMA, gebruik Factory Default-terugstelling om al die kliënt-spesifieke data te verwyder.
· Herstel van 'n gekompromitteerde toestel – As die sleutelmateriaal of geloofsbriewe wat op 'n toestel gestoor is, gekompromitteer is, stel die toestel terug na fabrieksopstelling en herkonfigureer dan die toestel.
· As dieselfde toestel op 'n ander terrein met 'n nuwe konfigurasie hergebruik moet word, voer 'n Fabrieksverstek-terugstelling uit om die bestaande konfigurasie te verwyder en dit na 'n skoon toestand te bring.

NFVIS bied die volgende opsies binne Fabrieksinstelling:

Fabrieksterugstelling opsie

Data uitgevee

Data behou

almal

Alle konfigurasie, opgelaaide beeld Die admin rekening word behou en

files, VM's en logs.

die wagwoord sal verander word na die

Konnektiwiteit aan die toestel sal die fabrieksstandaardwagwoord wees.

verlore.

Sekuriteitsoorwegings 21

Infrastruktuurbestuurnetwerk

Veiligheidsoorwegings

Fabrieksterugstelling-opsie alles-behalwe-beelde
alles-behalwe-beelde-konnektiwiteit
vervaardiging

Data uitgevee

Data behou

Alle konfigurasie behalwe beeld Beeldkonfigurasie, geregistreer

konfigurasie, VM'e en opgelaaide beelde en logs

beeld files.

Die admin rekening word behou en

Verbinding met die toestel sal die wagwoord verander word na die

verlore.

fabriek verstek wagwoord.

Alle konfigurasie behalwe beeld, beelde, netwerk en konneksie

netwerk en konneksie

verwante opset, geregistreer

konfigurasie, VM'e, en opgelaaide beelde, en logs.

beeld files.

Die admin rekening word behou en

Verbinding met die toestel is

die voorheen gekonfigureerde admin

beskikbaar.

wagwoord sal bewaar word.

Alle konfigurasie behalwe prentkonfigurasie, VM'e, opgelaaide prent files, en logs.
Verbinding met die toestel sal verlore gaan.

Beeldverwante konfigurasie en geregistreerde beelde
Die admin-rekening word behou en die wagwoord sal verander word na die fabrieksstandaardwagwoord.

Die gebruiker moet die toepaslike opsie versigtig kies op grond van die doel van die Fabrieksverstek-terugstelling. Vir meer inligting, sien Herstel na fabriekverstek.

Infrastruktuurbestuurnetwerk
'n Infrastruktuurbestuurnetwerk verwys na die netwerk wat die beheer- en bestuursvliegverkeer (soos NTP, SSH, SNMP, syslog, ens.) vir die infrastruktuurtoestelle dra. Toesteltoegang kan deur die konsole wees, sowel as deur die Ethernet-koppelvlakke. Hierdie beheer- en bestuurvliegtuigverkeer is van kritieke belang vir netwerkbedrywighede, wat sigbaarheid in en beheer oor die netwerk bied. Gevolglik is 'n goed ontwerpte en veilige infrastruktuurbestuursnetwerk van kritieke belang vir die algehele sekuriteit en bedrywighede van 'n netwerk. Een van die sleutelaanbevelings vir 'n veilige infrastruktuurbestuurnetwerk is die skeiding van bestuur- en dataverkeer ten einde afgeleë bestuurbaarheid te verseker selfs onder hoë vrag en hoë verkeerstoestande. Dit kan bereik word met behulp van 'n toegewyde bestuurskoppelvlak.
Die volgende is die infrastruktuurbestuurnetwerkimplementeringsbenaderings:
Buite-band Bestuur
'n Buitebandbestuur (OOB) bestuursnetwerk bestaan ​​uit 'n netwerk wat heeltemal onafhanklik en fisies verskil van die datanetwerk wat dit help bestuur. Dit word ook soms na verwys as 'n datakommunikasienetwerk (DCN). Netwerktoestelle kan op verskillende maniere aan die OOB-netwerk koppel: NFVIS ondersteun 'n ingeboude bestuurskoppelvlak wat gebruik kan word om aan die OOB-netwerk te koppel. NFVIS laat die opstelling van 'n voorafbepaalde fisiese koppelvlak, die MGMT-poort op die ENCS, as 'n toegewyde bestuurskoppelvlak toe. Die beperking van bestuurspakkette tot aangewese koppelvlakke bied groter beheer oor die bestuur van 'n toestel, waardeur meer sekuriteit vir daardie toestel verskaf word. Ander voordele sluit in verbeterde werkverrigting vir datapakkies op nie-bestuurskoppelvlakke, ondersteuning vir netwerkskaalbaarheid,

Sekuriteitsoorwegings 22

Veiligheidsoorwegings

Pseudo-buite-bandbestuur

behoefte aan minder toegangsbeheerlyste (ACL's) om toegang tot 'n toestel te beperk, en voorkoming dat bestuurspakketvloede die SVE bereik. Netwerktoestelle kan ook via toegewyde data-koppelvlakke aan die OOB-netwerk koppel. In hierdie geval moet ACL's ontplooi word om te verseker dat bestuursverkeer slegs deur die toegewyde koppelvlakke hanteer word. Vir verdere inligting, sien die konfigurasie van die IP-ontvangs-ACL en poort 22222 en bestuurskoppelvlak-ACL.
Pseudo-buite-bandbestuur
'n Pseudo-buite-band bestuursnetwerk gebruik dieselfde fisiese infrastruktuur as die datanetwerk, maar verskaf logiese skeiding deur die virtuele skeiding van verkeer, deur VLAN's te gebruik. NFVIS ondersteun die skep van VLAN's en virtuele brûe om verskillende bronne van verkeer te identifiseer en verkeer tussen VM's te skei. Om afsonderlike brûe en VLAN's te hê, isoleer die virtuele masjiennetwerk se dataverkeer en die bestuursnetwerk, en verskaf dus verkeersegmentering tussen die VM's en die gasheer. Vir verdere inligting sien VLAN konfigureer vir NFVIS Bestuursverkeer.
In-band Bestuur
'n In-band bestuursnetwerk gebruik dieselfde fisiese en logiese paaie as die dataverkeer. Uiteindelik vereis hierdie netwerkontwerp 'n per-kliënt-ontleding van risiko teenoor voordele en koste. Sommige algemene oorwegings sluit in:
· 'n Geïsoleerde OOB-bestuursnetwerk maksimeer sigbaarheid en beheer oor die netwerk selfs tydens ontwrigtende gebeurtenisse.
· Die oordrag van netwerktelemetrie oor 'n OOB-netwerk verminder die kans vir ontwrigting van die einste inligting wat kritieke netwerksigbaarheid bied.
· Binnebandbestuurtoegang tot netwerkinfrastruktuur, gashere, ens. is kwesbaar vir volledige verlies in die geval van 'n netwerkvoorval, wat al die netwerksigbaarheid en beheer verwyder. Gepaste QoS-kontroles moet in plek gestel word om hierdie voorkoms te versag.
· NFVIS beskik oor koppelvlakke wat toegewy is aan toestelbestuur, insluitend seriële konsolepoorte en Ethernet-bestuurskoppelvlakke.
· 'n OOB-bestuursnetwerk kan tipies teen 'n redelike koste ontplooi word, aangesien bestuursnetwerkverkeer nie tipies hoë bandwydte of hoëwerkverrigtingtoestelle vereis nie, en slegs voldoende poortdigtheid vereis om die konnektiwiteit na elke infrastruktuurtoestel te ondersteun.
Plaaslik gestoor inligting beskerming
Beskerming van sensitiewe inligting
NFVIS stoor sommige sensitiewe inligting plaaslik, insluitend wagwoorde en geheime. Wagwoorde moet oor die algemeen deur 'n gesentraliseerde AAA-bediener onderhou en beheer word. Selfs al word 'n gesentraliseerde AAA-bediener egter ontplooi, word sommige plaaslik-gebergde wagwoorde vereis vir sekere gevalle, soos plaaslike terugval in die geval van AAA-bedieners wat nie beskikbaar is nie, spesiale gebruik gebruikersname, ens. Hierdie plaaslike wagwoorde en ander sensitiewe

Sekuriteitsoorwegings 23

File Oordrag

Veiligheidsoorwegings

inligting word op NFVIS as hashes gestoor sodat dit nie moontlik is om die oorspronklike geloofsbriewe van die stelsel te herwin nie. Hashing is 'n algemeen aanvaarde industrienorm.

File Oordrag
Files wat dalk na NFVIS-toestelle oorgedra moet word, sluit in VM-beeld en NFVIS-opgradering files. Die veilige oordrag van files is krities vir netwerkinfrastruktuursekuriteit. NFVIS ondersteun Secure Copy (SCP) om die sekuriteit van te verseker file oordrag. SCP maak staat op SSH vir veilige verifikasie en vervoer, wat die veilige en geverifieerde kopiëring van files.
'n Veilige kopie van NFVIS word geïnisieer deur die scp-opdrag. Die veilige kopie (scp) opdrag laat slegs die admin gebruiker toe om veilig te kopieer files van NFVIS na 'n eksterne stelsel, of van 'n eksterne stelsel na NFVIS.
Die sintaksis vir die scp-opdrag is:
skp
Ons gebruik poort 22222 vir die NFVIS SCP-bediener. By verstek is hierdie poort gesluit en gebruikers kan nie kopie beveilig nie files in NFVIS van 'n eksterne kliënt. As daar 'n behoefte is om SCP a file vanaf 'n eksterne kliënt kan die gebruiker die poort oopmaak deur:
stelsel instellings ip-ontvang-acl (adres)/(masker lengte) diens scpd prioriteit (nommer) aksie aanvaar
pleeg
Om te verhoed dat gebruikers toegang tot stelselgidse kry, kan veilige kopie slegs na of vanaf intdatastore:, extdatastore1:, extdatastore2:, usb: en nfs: uitgevoer word, indien beskikbaar. Veilige kopie kan ook vanaf logs uitgevoer word: en tegniese ondersteuning:

Tekening

NFVIS-toegang en konfigurasieveranderinge word as ouditloglêers aangeteken om die volgende inligting aan te teken: · Wie het toegang tot die toestel verkry · Wanneer het 'n gebruiker aangemeld · Wat het 'n gebruiker gedoen in terme van die gasheeropstelling en die VM-lewensiklus · Wanneer het 'n gebruiker aangemeld af · Mislukte toegangspogings · Mislukte stawingversoeke · Mislukte magtigingsversoeke
Hierdie inligting is van onskatbare waarde vir forensiese ontleding in geval van ongemagtigde pogings of toegang, sowel as vir konfigurasieveranderingkwessies en om groepadministrasieveranderinge te help beplan. Dit kan ook intyds gebruik word om abnormale aktiwiteite te identifiseer wat kan aandui dat 'n aanval plaasvind. Hierdie ontleding kan gekorreleer word met inligting van bykomende eksterne bronne, soos IDS en firewall logs.

Sekuriteitsoorwegings 24

Veiligheidsoorwegings

Virtuele masjien sekuriteit

Al die sleutelgebeurtenisse op die NFVIS word as gebeurteniskennisgewings aan NETCONF-intekenare gestuur en as syslogs na die gekonfigureerde sentrale aantekenbedieners. Vir meer inligting oor syslog-boodskappe en gebeurteniskennisgewings, sien Bylaag.
Virtuele masjien sekuriteit
Hierdie afdeling beskryf sekuriteitskenmerke wat verband hou met die registrasie, ontplooiing en werking van virtuele masjiene op NFVIS.
VNF veilige selflaai
NFVIS ondersteun Open Virtual Machine Firmware (OVMF) om UEFI veilige selflaai vir virtuele masjiene wat veilige selflaai ondersteun, moontlik te maak. VNF Secure boot verifieer dat elke laag van die VM-selflaaisagteware onderteken is, insluitend die selflaaiprogram, die bedryfstelselkern en bedryfstelselbestuurders.

Vir meer inligting, sien Veilige opstart van VNF's.
VNC Console Toegangsbeskerming
NFVIS laat die gebruiker toe om 'n Virtual Network Computing (VNC) sessie te skep om toegang te verkry tot 'n ontplooide VM se afgeleë lessenaar. Om dit moontlik te maak, maak NFVIS 'n poort dinamies oop waaraan die gebruiker kan koppel met hul web blaaier. Hierdie poort word slegs vir 60 sekondes oopgelaat vir 'n eksterne bediener om 'n sessie na die VM te begin. As geen aktiwiteit binne hierdie tyd gesien word nie, is die hawe gesluit. Die poortnommer word dinamies toegeken en laat daardeur slegs 'n eenmalige toegang tot die VNC-konsole toe.
nfvis# vncconsole begin ontplooiing-naam 1510614035 vm-naam ROUTER vncconsole-url :6005/vnc_auto.html
Wys jou blaaier na https:// :6005/vnc_auto.html sal aan die ROUTER VM se VNC-konsole koppel.
Sekuriteitsoorwegings 25

Geënkripteerde VM-konfigurasie-dataveranderlikes

Veiligheidsoorwegings

Geënkripteerde VM-konfigurasie-dataveranderlikes
Tydens VM-ontplooiing verskaf die gebruiker 'n dag-0-konfigurasie file vir die VM. Hierdie file kan sensitiewe inligting soos wagwoorde en sleutels bevat. As hierdie inligting as duidelike teks deurgegee word, verskyn dit in log files en interne databasisrekords in duidelike teks. Hierdie kenmerk laat die gebruiker toe om 'n konfigurasiedataveranderlike as sensitief te vlag sodat die waarde daarvan geïnkripteer word met AES-CFB-128-enkripsie voordat dit gestoor of na interne substelsels oorgedra word.
Vir meer inligting, sien VM-ontplooiingsparameters.
Kontrolesom-verifikasie vir afstandbeeldregistrasie
Om 'n afstand geleë VNF-beeld te registreer, spesifiseer die gebruiker sy ligging. Die prent sal van 'n eksterne bron afgelaai moet word, soos 'n NFS-bediener of 'n afgeleë HTTPS-bediener.
Om te weet of 'n afgelaai file veilig is om te installeer, is dit noodsaaklik om die te vergelyk filese kontrolesom voordat dit gebruik word. Deur die kontrolesom te verifieer help om te verseker dat die file is nie beskadig tydens netwerkoordrag nie, of deur 'n kwaadwillige derde party gewysig voordat jy dit afgelaai het nie.
NFVIS ondersteun die kontrolesom- en kontrolesomalgoritme-opsies vir die gebruiker om die verwagte kontrolesom- en kontrolesomalgoritme (SHA256 of SHA512) te verskaf wat gebruik moet word om die kontrolesom van die afgelaaide prent te verifieer. Beeldskepping misluk as die kontrolesom nie ooreenstem nie.
Sertifisering Validasie vir Afgeleë Beeld Registrasie
Om 'n VNF-beeld wat op 'n HTTPS-bediener geleë is te registreer, sal die beeld van die afgeleë HTTPS-bediener afgelaai moet word. Om hierdie prent veilig af te laai, verifieer NFVIS die SSL-sertifikaat van die bediener. Die gebruiker moet óf die pad na die sertifikaat spesifiseer file of die PEM-formaat sertifikaatinhoud om hierdie veilige aflaai moontlik te maak.
Meer besonderhede kan gevind word by Afdeling oor sertifikaatbekragtiging vir beeldregistrasie
VM-isolasie en hulpbronvoorsiening
Die Network Function Virtualization (NFV) argitektuur bestaan ​​uit:
· Gevirtualiseerde netwerkfunksies (VNF's), wat virtuele masjiene is wat sagtewaretoepassings gebruik wat netwerkfunksionaliteit lewer, soos 'n roeteerder, brandmuur, lasbalanseerder, ensovoorts.
· Netwerkfunksies virtualisasie-infrastruktuur, wat bestaan ​​uit die infrastruktuurkomponente – rekenaar, geheue, berging en netwerk, op 'n platform wat die vereiste sagteware en hiperviser ondersteun.
Met NFV word netwerkfunksies gevirtualiseer sodat verskeie funksies op 'n enkele bediener uitgevoer kan word. As gevolg hiervan is minder fisiese hardeware nodig, wat voorsiening maak vir hulpbronkonsolidasie. In hierdie omgewing is dit noodsaaklik om toegewyde hulpbronne vir veelvuldige VNF's te simuleer vanaf 'n enkele, fisiese hardewarestelsel. Deur NFVIS te gebruik, kan VM's op 'n beheerde wyse ontplooi word sodat elke VM die hulpbronne ontvang wat dit benodig. Hulpbronne word soos nodig verdeel van die fisiese omgewing na die vele virtuele omgewings. Die individuele VM-domeine is geïsoleer sodat hulle afsonderlike, afsonderlike en veilige omgewings is wat nie met mekaar veg vir gedeelde hulpbronne nie.
VM'e kan nie meer hulpbronne gebruik as wat voorsien is nie. Dit vermy 'n diensweiertoestand van een VM wat die hulpbronne verbruik. As gevolg hiervan word SVE, geheue, netwerk en berging beskerm.

Sekuriteitsoorwegings 26

Veiligheidsoorwegings
SVE isolasie

SVE isolasie

Die NFVIS-stelsel behou kerns vir die infrastruktuursagteware wat op die gasheer loop. Die res van die kerne is beskikbaar vir VM-ontplooiing. Dit waarborg dat die VM se werkverrigting nie die NFVIS-gasheerprestasie beïnvloed nie. Lae-latency VM's NFVIS ken uitdruklik toegewyde kerns toe aan lae latency VM's wat daarop ontplooi word. As die VM 2 vCPU's benodig, word 2 toegewyde kerne daaraan toegeken. Dit voorkom die deel en oorintekening van kerns en waarborg die werkverrigting van die lae-latency VM's. As die aantal beskikbare kerns minder is as die aantal vCPU's wat deur 'n ander lae-latency VM aangevra is, word die ontplooiing verhoed aangesien ons nie voldoende hulpbronne het nie. Nie-lae-latency VM's NFVIS ken deelbare SVE's toe aan nie-lae latency VM's. As die VM 2 vCPU's benodig, word 2 CPU's daaraan toegeken. Hierdie 2 SVE's is deelbaar onder ander nie-lae latency VM's. As die aantal beskikbare SVE's minder is as die aantal vCPU's wat deur 'n ander nie-lae-latency VM versoek is, word die ontplooiing steeds toegelaat omdat hierdie VM die SVE sal deel met bestaande nie-lae latensie VM's.
Geheuetoewysing
Die NFVIS-infrastruktuur vereis 'n sekere hoeveelheid geheue. Wanneer 'n VM ontplooi word, is daar 'n kontrole om te verseker dat die geheue wat beskikbaar is nadat die geheue wat benodig word vir die infrastruktuur en voorheen ontplooide VM's gereserveer is, voldoende is vir die nuwe VM. Ons laat nie geheue oorintekening vir die VM'e toe nie.
Sekuriteitsoorwegings 27

Berging isolasie
VM's word nie toegelaat om direk toegang tot die gasheer te kry nie file stelsel en berging.
Berging isolasie

Veiligheidsoorwegings

Die ENCS-platform ondersteun 'n interne datastoor (M2 SSD) en eksterne skywe. NFVIS is op die interne datastoor geïnstalleer. VNF's kan ook op hierdie interne datastoor ontplooi word. Dit is 'n beste praktyk vir sekuriteit om kliëntedata te stoor en virtuele masjiene vir kliënte te ontplooi op die eksterne skywe. Met fisies aparte skywe vir die stelsel files vs die aansoek files help om stelseldata teen korrupsie en sekuriteitskwessies te beskerm.
·
Interface isolasie
Enkelwortel I/O-virtualisering of SR-IOV is 'n spesifikasie wat die isolasie van PCI Express (PCIe) hulpbronne soos 'n Ethernet-poort moontlik maak. Met behulp van SR-IOV kan 'n enkele Ethernet-poort gemaak word om te verskyn as veelvuldige, afsonderlike, fisiese toestelle bekend as virtuele funksies. Al die VF-toestelle op daardie adapter deel dieselfde fisiese netwerkpoort. 'n Gas kan een of meer van hierdie virtuele funksies gebruik. 'n Virtuele funksie verskyn vir die gas as 'n netwerkkaart, op dieselfde manier as wat 'n normale netwerkkaart vir 'n bedryfstelsel sou verskyn. Virtuele funksies het byna oorspronklike werkverrigting en bied beter werkverrigting as para-gevirtualiseerde drywers en nagebootste toegang. Virtuele funksies bied databeskerming tussen gaste op dieselfde fisiese bediener aangesien die data deur die hardeware bestuur en beheer word. NFVIS VNF's kan SR-IOV-netwerke gebruik om aan WAN en LAN Backplane-poorte te koppel.
Sekuriteitsoorwegings 28

Veiligheidsoorwegings

Veilige ontwikkelingslewensiklus

Elke sodanige VM besit 'n virtuele koppelvlak en sy verwante hulpbronne wat databeskerming onder VM's bereik.
Veilige ontwikkelingslewensiklus
NFVIS volg 'n veilige ontwikkelingslewensiklus (SDL) vir sagteware. Dit is 'n herhaalbare, meetbare proses wat ontwerp is om kwesbaarhede te verminder en die sekuriteit en veerkragtigheid van Cisco-oplossings te verbeter. Cisco SDL pas toonaangewende praktyke en tegnologie toe om betroubare oplossings te bou wat minder produksekuriteitsvoorvalle in die veld ontdek het. Elke NFVIS-vrystelling gaan deur die volgende prosesse.
· Na aanleiding van Cisco-interne en markgebaseerde produksekuriteitsvereistes · Registrasie van derdeparty-sagteware met 'n sentrale bewaarplek by Cisco vir kwesbaarheidopsporing. · Ontwerp sagteware met sekuriteit in gedagte · Volg veilige koderingspraktyke soos die gebruik van gekeurde algemene sekuriteitsmodules soos CiscoSSL, loop
Statiese Analise en implementering van insetvalidering vir die Voorkoming van bevelinspuiting, ens. · Die gebruik van Toepassingsekuriteitsinstrumente soos IBM AppScan, Nessus en ander interne Cisco-instrumente.

Sekuriteitsoorwegings 29

Veilige ontwikkelingslewensiklus

Veiligheidsoorwegings

Sekuriteitsoorwegings 30

Dokumente / Hulpbronne

CISCO Enterprise Network Funksie Virtualisering Infrastruktuur Sagteware [pdf] Gebruikersgids Ondernemingsnetwerkfunksie Virtualisering-infrastruktuursagteware, Onderneming, Netwerkfunksie-virtualisering-infrastruktuursagteware, Virtualisering-infrastruktuursagteware, Infrastruktuursagteware

Verwysings

• Gebruikershandleiding