Enterprise Network Function Virtualization Infrastructure Software
Produktinformasjon
Spesifikasjoner
- NFVIS programvareversjon: 3.7.1 og nyere
- RPM-signering og signaturverifisering støttes
- Sikker oppstart tilgjengelig (deaktivert som standard)
- Secure Unique Device Identification (SUDI)-mekanisme brukt
Sikkerhetshensyn
NFVIS-programvaren sørger for sikkerhet gjennom div
mekanismer:
- Bilde Tamper Beskyttelse: RPM-signering og signaturverifisering
for alle RPM-pakker i ISO og oppgraderingsbilder. - RPM-signering: Alle RPM-pakker i Cisco Enterprise NFVIS ISO
og oppgraderingsbilder er signert for å sikre kryptografisk integritet og
autentisitet. - RPM-signaturverifisering: Signaturen til alle RPM-pakker er
verifisert før installasjon eller oppgradering. - Verifikasjon av bildeintegritet: Hash for Cisco NFVIS ISO-bildet
og oppgraderingsbilde er publisert for å sikre integriteten til ytterligere
ikke-RPM files. - ENCS Secure Boot: En del av UEFI-standarden, sikrer at
enheten starter bare opp med pålitelig programvare. - Secure Unique Device Identification (SUDI): Gir enheten
med en uforanderlig identitet for å bekrefte dens ekthet.
Installasjon
Følg disse trinnene for å installere NFVIS-programvaren:
- Kontroller at programvarebildet ikke har blitt tampered med av
verifisere sin signatur og integritet. - Hvis du bruker Cisco Enterprise NFVIS 3.7.1 og nyere, sørg for at
signaturverifiseringen passerer under installasjonen. Hvis det mislykkes,
installasjonen vil bli avbrutt. - Hvis du oppgraderer fra Cisco Enterprise NFVIS 3.6.x til utgivelse
3.7.1, RPM-signaturene verifiseres under oppgraderingen. Hvis
signaturverifisering mislykkes, en feil logges, men oppgraderingen er det
fullført. - Hvis du oppgraderer fra versjon 3.7.1 til senere utgivelser, vil RPM
signaturer verifiseres når oppgraderingsbildet er registrert. Hvis
signaturverifiseringen mislykkes, oppgraderingen avbrytes. - Bekreft hashen til Cisco NFVIS ISO-bildet eller oppgraderingsbildet
ved å bruke kommandoen:/usr/bin/sha512sum. Sammenlign hashen med den publiserte
<image_filepath>
hasj for å sikre integritet.
Sikker oppstart
Sikker oppstart er en funksjon tilgjengelig på ENCS (deaktivert som standard)
som sikrer at enheten bare starter opp med pålitelig programvare. Til
aktiver sikker oppstart:
- Se dokumentasjonen om Secure Boot of Host for mer
informasjon. - Følg instruksjonene som følger med for å aktivere sikker oppstart på din
enhet.
Sikker unik enhetsidentifikasjon (SUDI)
SUDI gir NFVIS en uforanderlig identitet, som bekrefter det
det er et ekte Cisco-produkt og sikrer dets anerkjennelse i
kundens lagersystem.
FAQ
Spørsmål: Hva er NFVIS?
A: NFVIS står for Network Function Virtualization
Infrastruktur programvare. Det er en programvareplattform som brukes til å distribuere
og administrere virtuelle nettverksfunksjoner.
Spørsmål: Hvordan kan jeg verifisere integriteten til NFVIS ISO-bildet eller
oppgradere bildet?
A: For å bekrefte integriteten, bruk kommandoen
/usr/bin/sha512sum <image_filepath> og sammenlign
hashen med den publiserte hashen levert av Cisco.
Spørsmål: Er sikker oppstart aktivert som standard på ENCS?
A: Nei, sikker oppstart er deaktivert som standard på ENCS. Det er
anbefales for å aktivere sikker oppstart for økt sikkerhet.
Spørsmål: Hva er formålet med SUDI i NFVIS?
A: SUDI gir NFVIS en unik og uforanderlig identitet,
sikre ekteheten som et Cisco-produkt og legge til rette for det
gjenkjennelse i kundens lagersystem.
Sikkerhetshensyn
Dette kapittelet beskriver sikkerhetsfunksjonene og hensynene i NFVIS. Det gir et høyt nivå overview av sikkerhetsrelaterte komponenter i NFVIS for å planlegge en sikkerhetsstrategi for distribusjoner som er spesifikke for deg. Den har også anbefalinger om beste praksis for sikkerhet for å håndheve kjerneelementene i nettverkssikkerhet. NFVIS-programvaren har sikkerhet innebygd helt fra installasjonen gjennom alle programvarelag. De påfølgende kapitlene fokuserer på disse ut-av-boksen sikkerhetsaspekter som legitimasjonsadministrasjon, integritet og tamper-beskyttelse, øktadministrasjon, sikker enhetstilgang og mer.
· Installasjon, på side 2 · Sikker unik enhetsidentifikasjon, på side 3 · Enhetstilgang, på side 4
Sikkerhetshensyn 1
Installasjon
Sikkerhetshensyn
· Infrastructure Management Network, på side 22 · Lokalt lagret informasjonsbeskyttelse, på side 23 · File Overføring, på side 24 · Logging, på side 24 · Virtual Machine-sikkerhet, på side 25 · VM-isolering og ressursklargjøring, på side 26 · Sikker utviklingslivssyklus, på side 29
Installasjon
For å sikre at NFVIS-programvaren ikke har blitt tampmed , verifiseres programvarebildet før installasjon ved hjelp av følgende mekanismer:
Bilde Tamper beskyttelse
NFVIS støtter RPM-signering og signaturverifisering for alle RPM-pakker i ISO- og oppgraderingsbildene.
RPM-signering
Alle RPM-pakker i Cisco Enterprise NFVIS ISO og oppgraderingsbilder er signert for å sikre kryptografisk integritet og autentisitet. Dette garanterer at RPM-pakkene ikke har blitt tampered with og RPM-pakkene er fra NFVIS. Den private nøkkelen som brukes til å signere RPM-pakkene er opprettet og vedlikeholdt av Cisco.
RPM-signaturverifisering
NFVIS-programvaren verifiserer signaturen til alle RPM-pakkene før en installasjon eller oppgradering. Tabellen nedenfor beskriver Cisco Enterprise NFVIS-atferden når signaturverifiseringen mislykkes under en installasjon eller oppgradering.
Scenario
Beskrivelse
Cisco Enterprise NFVIS 3.7.1 og senere installasjoner Hvis signaturverifiseringen mislykkes mens du installerer Cisco Enterprise NFVIS, avbrytes installasjonen.
Cisco Enterprise NFVIS-oppgradering fra 3.6.x til versjon 3.7.1
RPM-signaturene verifiseres når oppgraderingen utføres. Hvis signaturverifiseringen mislykkes, logges en feil, men oppgraderingen er fullført.
Cisco Enterprise NFVIS-oppgradering fra versjon 3.7.1 RPM-signaturene verifiseres ved oppgraderingen
til senere utgivelser
bildet er registrert. Hvis signaturverifiseringen mislykkes,
oppgraderingen avbrytes.
Verifisering av bildeintegritet
RPM-signering og signaturverifisering kan bare gjøres for RPM-pakkene som er tilgjengelige i Cisco NFVIS ISO og oppgraderingsbilder. For å sikre integriteten til alle de ekstra ikke-RPM fileer tilgjengelig i Cisco NFVIS ISO-bildet, publiseres en hash av Cisco NFVIS ISO-bildet sammen med bildet. På samme måte publiseres en hash av Cisco NFVIS-oppgraderingsbildet sammen med bildet. For å bekrefte at hashen til Cisco
Sikkerhetshensyn 2
Sikkerhetshensyn
ENCS sikker oppstart
NFVIS ISO-bilde eller oppgraderingsbilde samsvarer med hashen publisert av Cisco, kjør følgende kommando og sammenlign hashen med den publiserte hashen:
% /usr/bin/sha512sumFile> c2122783efc18b039246ae1bcd4eec4e5e027526967b5b809da5632d462dfa6724a9b20ec318c74548c6bd7e9b8217ce96b5ece93dcdd74fda5e01bb382ad607
<ImageFile>
ENCS sikker oppstart
Sikker oppstart er en del av UEFI-standarden (Unified Extensible Firmware Interface) som sikrer at en enhet kun starter opp ved hjelp av programvare som er klarert av Original Equipment Manufacturer (OEM). Når NFVIS starter, kontrollerer fastvaren signaturen til oppstartsprogramvaren og operativsystemet. Hvis signaturene er gyldige, starter enheten, og fastvaren gir kontrollen til operativsystemet.
Sikker oppstart er tilgjengelig på ENCS, men er deaktivert som standard. Cisco anbefaler deg å aktivere sikker oppstart. For mer informasjon, se Secure Boot of Host.
Sikker unik enhetsidentifikasjon
NFVIS bruker en mekanisme kjent som Secure Unique Device Identification (SUDI), som gir den en uforanderlig identitet. Denne identiteten brukes til å bekrefte at enheten er et ekte Cisco-produkt, og for å sikre at enheten er godt kjent for kundens lagersystem.
SUDI er et X.509v3-sertifikat og et tilhørende nøkkelpar som er beskyttet i maskinvare. SUDI-sertifikatet inneholder produktidentifikatoren og serienummeret og er forankret i Cisco Public Key Infrastructure. Nøkkelparet og SUDI-sertifikatet settes inn i maskinvaremodulen under produksjon, og den private nøkkelen kan aldri eksporteres.
Den SUDI-baserte identiteten kan brukes til å utføre autentisert og automatisert konfigurasjon ved hjelp av Zero Touch Provisioning (ZTP). Dette muliggjør sikker, ekstern onboarding av enheter, og sikrer at orkestreringsserveren snakker med en ekte NFVIS-enhet. A backend system can issue a challenge to the NFVIS device to validate its identity and the device will respond to the challenge using its SUDI based identity. This allows the backend system to not only verify against its inventory that the right device is in the right location but also provide encrypted configuration that can only be opened by the specific device, thereby ensuring confidentiality in transit.
Følgende arbeidsflytdiagrammer illustrerer hvordan NFVIS bruker SUDI:
Sikkerhetshensyn 3
Enhetstilgang Figur 1: Plug and Play (PnP) serverautentisering
Sikkerhetshensyn
Figur 2: Plug and Play-enhetsgodkjenning og autorisasjon
Enhetstilgang
NFVIS provides different access mechanisms including console as well as remote access based on protocols such as HTTPS and SSH. Hver tilgangsmekanisme bør revideres nøyeviewed og konfigurert. Sørg for at bare de nødvendige tilgangsmekanismene er aktivert og at de er ordentlig sikret. Nøkkeltrinnene for å sikre både interaktiv tilgang og administrasjonstilgang til NFVIS er å begrense enhetens tilgjengelighet, begrense mulighetene til de tillatte brukerne til det som kreves, og begrense de tillatte tilgangsmetodene. NFVIS sikrer at tilgangen kun gis til autentiserte brukere, og de kan utføre kun de autoriserte handlingene. Enhetstilgang logges for revisjon og NFVIS sikrer konfidensialiteten til lokalt lagrede sensitive data. Det er avgjørende å etablere passende kontroller for å forhindre uautorisert tilgang til NFVIS. Følgende avsnitt beskriver beste praksis og konfigurasjoner for å oppnå dette:
Sikkerhetshensyn 4
Sikkerhetshensyn
Tvunget passordendring ved første pålogging
Tvunget passordendring ved første pålogging
Standardlegitimasjon er en hyppig kilde til produktsikkerhetshendelser. Kunder glemmer ofte å endre standard påloggingsinformasjon og lar systemene deres være åpne for angrep. For å forhindre dette, blir NFVIS-brukeren tvunget til å endre passordet etter første pålogging ved å bruke standardlegitimasjonen (brukernavn: admin og passord Admin123#). For mer informasjon, se Tilgang til NFVIS.
Begrense påloggingssårbarheter
Du kan forhindre sårbarheten for ordbok- og DoS-angrep (Denial of Service) ved å bruke følgende funksjoner.
Håndheving av sterkt passord
En autentiseringsmekanisme er bare så sterk som dens legitimasjon. Av denne grunn er det viktig å sikre at brukerne har sterke passord. NFVIS sjekker at et sterkt passord er konfigurert i henhold til følgende regler: Passord må inneholde:
· Minst ett stort tegn · Minst ett lite tegn · Minst ett tall · Minst ett av disse spesialtegnene: hash (#), understrek (_), bindestrek (-), stjerne (*) eller spørsmål
merke (?) · Sju tegn eller mer · Passordlengden skal være mellom 7 og 128 tegn.
Konfigurere minimumslengde for passord
Mangel på passordkompleksitet, spesielt passordlengde, reduserer søkeområdet betraktelig når angripere prøver å gjette brukerpassord, noe som gjør brute-force-angrep mye enklere. Administratorbrukeren kan konfigurere minimumslengden som kreves for passord for alle brukere. Minimumslengden må være mellom 7 og 128 tegn. Som standard er minimumslengden som kreves for passord satt til 7 tegn. CLI:
nfvis(config)# rbac-autentisering min-pwd-length 9
API:
/api/config/rbac/autentisering/min-pwd-length
Konfigurere passordlevetid
Passordets levetid avgjør hvor lenge et passord kan brukes før brukeren må endre det.
Sikkerhetshensyn 5
Begrens tidligere gjenbruk av passord
Sikkerhetshensyn
Administratorbrukeren kan konfigurere minimums- og maksimumsverdier for levetid for passord for alle brukere og håndheve en regel for å kontrollere disse verdiene. Standard minimum levetidsverdi er satt til 1 dag og standard maksimal levetidsverdi er satt til 60 dager. Når en minimum levetidsverdi er konfigurert, kan ikke brukeren endre passordet før det angitte antallet dager har gått. På samme måte, når en maksimal levetidsverdi er konfigurert, må en bruker endre passordet før det angitte antallet dager går. Hvis en bruker ikke endrer passordet og det angitte antall dager har gått, sendes et varsel til brukeren.
Merk Minimums- og maksimumsverdiene for levetid og regelen for å se etter disse verdiene brukes ikke på administratorbrukeren.
CLI:
konfigurer terminal rbac-autentisering passord-levetid håndheve sanne min-dager 2 maks-dager 30 commit
API:
/api/config/rbac/autentisering/password-lifetime/
Begrens tidligere gjenbruk av passord
Uten å forhindre bruk av tidligere passordfraser, er passordutløp stort sett ubrukelig siden brukere ganske enkelt kan endre passordfrasen og deretter endre den tilbake til originalen. NFVIS kontrollerer at det nye passordet ikke er det samme som et av de 5 tidligere brukte passordene. Et unntak fra denne regelen er at admin-brukeren kan endre passordet til standardpassordet selv om det var ett av de 5 tidligere brukte passordene.
Begrens hyppigheten av påloggingsforsøk
Hvis en ekstern peer får lov til å logge på et ubegrenset antall ganger, kan den til slutt være i stand til å gjette påloggingsinformasjonen med brute force. Siden passordfraser ofte er enkle å gjette, er dette et vanlig angrep. Ved å begrense frekvensen som peeren kan forsøke pålogging med, forhindrer vi dette angrepet. We also avoid spending the system resources on unnecessarily authenticating these brute-force login attempts which could create a Denial of Service attack. NFVIS håndhever en 5 minutters brukersperring etter 10 mislykkede påloggingsforsøk.
Deaktiver inaktive brukerkontoer
Overvåking av brukeraktivitet og deaktivering av ubrukte eller foreldede brukerkontoer bidrar til å sikre systemet mot innsideangrep. De ubrukte kontoene bør til slutt fjernes. Administratorbrukeren kan håndheve en regel for å merke ubrukte brukerkontoer som inaktive og konfigurere antall dager etter at en ubrukt brukerkonto blir merket som inaktiv. Når den er merket som inaktiv, kan ikke denne brukeren logge på systemet. For å la brukeren logge på systemet, kan adminbrukeren aktivere brukerkontoen.
Merk Inaktivitetsperioden og regelen for å kontrollere inaktivitetsperioden brukes ikke på administratorbrukeren.
Sikkerhetshensyn 6
Sikkerhetshensyn
Aktivering av en inaktiv brukerkonto
Følgende CLI og API kan brukes til å konfigurere håndhevelsen av kontoinaktivitet. CLI:
konfigurer terminal rbac-autentisering konto-inaktivitet håndheve ekte inaktivitet-dager 30 commit
API:
/api/config/rbac/autentisering/kontoinaktivitet/
Standardverdien for inaktivitetsdager er 35.
Aktivere en inaktiv brukerkonto Administratorbrukeren kan aktivere kontoen til en inaktiv bruker ved å bruke følgende CLI og API: CLI:
konfigurer terminal rbac autentisering brukere bruker gjest_bruker aktivere commit
API:
/api/operations/rbac/autentisering/brukere/bruker/brukernavn/aktiver
Håndhev innstilling av BIOS- og CIMC-passord
Tabell 1: Tabell over funksjonshistorikk
Funksjonsnavn
Utgivelsesinformasjon
Håndhev innstilling av BIOS- og CIMC NFVIS 4.7.1-passord
Beskrivelse
Denne funksjonen tvinger brukeren til å endre standardpassordet for CIMC og BIOS.
Restriksjoner for å håndheve innstilling av BIOS- og CIMC-passord
· Denne funksjonen støttes kun på Cisco Catalyst 8200 UCPE og Cisco ENCS 5400-plattformer.
· Denne funksjonen støttes kun på en ny installasjon av NFVIS 4.7.1 og senere utgivelser. Hvis du oppgraderer fra NFVIS 4.6.1 til NFVIS 4.7.1, støttes ikke denne funksjonen, og du blir ikke bedt om å tilbakestille BIOS- og CIMS-passordene, selv om BIOS- og CIMC-passordene ikke er konfigurert.
Informasjon om håndheving av innstilling av BIOS- og CIMC-passord
Denne funksjonen løser et sikkerhetshull ved å tvinge tilbakestilling av BIOS- og CIMC-passordene etter en ny installasjon av NFVIS 4.7.1. Standard CIMC-passord er passord og standard BIOS-passord er ikke noe passord.
For å fikse sikkerhetshullet, tvinges du til å konfigurere BIOS- og CIMC-passordene i ENCS 5400. Under en ny installasjon av NFVIS 4.7.1, hvis BIOS- og CIMC-passordene ikke er endret og fortsatt har
Sikkerhetshensyn 7
Konfigurasjon Eksamples for tvungen tilbakestilling av BIOS- og CIMC-passord
Sikkerhetshensyn
standardpassordene, blir du bedt om å endre både BIOS- og CIMC-passordene. Hvis bare én av dem krever tilbakestilling, blir du bedt om å tilbakestille passordet for kun den komponenten. Cisco Catalyst 8200 UCPE krever bare BIOS-passordet, og derfor blir bare BIOS-passordet tilbakestilt, hvis det ikke allerede er satt.
Merk Hvis du oppgraderer fra en tidligere versjon til NFVIS 4.7.1 eller nyere utgivelser, kan du endre BIOS- og CIMC-passordene ved å bruke kommandoene hostaction change-bios-password newpassword eller hostaction change-cimc-password newpassword.
For mer informasjon om BIOS- og CIMC-passord, se BIOS og CIMC-passord.
Konfigurasjon Eksamples for tvungen tilbakestilling av BIOS- og CIMC-passord
1. Når du installerer NFVIS 4.7.1, må du først tilbakestille standard administratorpassord.
Cisco Network Function Virtualization Infrastructure Software (NFVIS)
NFVIS-versjon: 99.99.0-1009
Copyright (c) 2015-2021 av Cisco Systems, Inc. Cisco, Cisco Systems og Cisco Systems-logoen er registrerte varemerker for Cisco Systems, Inc. og/eller dets tilknyttede selskaper i USA og visse andre land.
Opphavsretten til visse verk i denne programvaren eies av andre tredjeparter og brukes og distribueres under tredjeparts lisensavtaler. Enkelte komponenter i denne programvaren er lisensiert under GNU GPL 2.0, GPL 3.0, LGPL 2.1, LGPL 3.0 og AGPL 3.0.
admin koblet til fra 10.24.109.102 ved hjelp av ssh på nfvis admin logget med standard påloggingsinformasjon Vennligst oppgi et passord som tilfredsstiller følgende kriterier:
1.Minst ett liten bokstav 2.Minst ett stort tegn 3.Minst ett tall 4.Minst ett spesialtegn fra # _ – * ? 5.Lengden skal være mellom 7 og 128 tegn. Tilbakestill passordet: Vennligst skriv inn passordet på nytt:
Tilbakestiller administratorpassord
2. På Cisco Catalyst 8200 UCPE- og Cisco ENCS 5400-plattformer når du gjør en ny installasjon av NFVIS 4.7.1 eller nyere utgivelser, må du endre standard BIOS- og CIMC-passord. Hvis BIOS- og CIMC-passordene ikke er konfigurert tidligere, ber systemet deg om å tilbakestille BIOS- og CIMC-passordene for Cisco ENCS 5400 og bare BIOS-passordet for Cisco Catalyst 8200 UCPE.
Nytt administratorpassord er satt
Vennligst oppgi BIOS-passordet som tilfredsstiller følgende kriterier: 1. Minst ett stort tegn 2. Minst ett stort tegn 3. Minst ett tall 4. Minst ett spesialtegn fra #, @ eller _ 5. Lengden skal være mellom 8 og 20 tegn 6. Bør ikke inneholde noen av følgende strenger (skiller mellom store og små bokstaver): bios 7. Det første tegnet kan ikke være et #
Sikkerhetshensyn 8
Sikkerhetshensyn
Bekreft BIOS- og CIMC-passord
Tilbakestill BIOS-passordet: Vennligst skriv inn BIOS-passordet på nytt: Vennligst oppgi CIMC-passordet som tilfredsstiller følgende kriterier:
1. Minst ett stort tegn 2. Minst ett stort tegn 3. Minst ett tall 4. Minst ett spesialtegn fra #, @ eller _ 5. Lengden skal være mellom 8 og 20 tegn 6. Bør ikke inneholde noen av følgende strenger (skiller mellom store og små bokstaver): admin Tilbakestill CIMC-passordet: Vennligst skriv inn CIMC-passordet på nytt:
Bekreft BIOS- og CIMC-passord
For å verifisere om BIOS- og CIMC-passordene er endret, bruk showloggen nfvis_config.log | inkludere BIOS eller vis logg nfvis_config.log | inkluderer CIMC-kommandoer:
nfvis# vis logg nfvis_config.log | inkluderer BIOS
2021-11-16 15:24:40,102 INFO
[hostaction:/system/settings] [] BIOS-passordendringer vellykket
Du kan også laste ned nfvis_config.log file og kontroller om passordene er tilbakestilt.
Integrasjon med eksterne AAA-servere
Brukere logger på NFVIS via ssh eller Web UI. I begge tilfeller må brukere autentiseres. Det vil si at en bruker må presentere passordlegitimasjon for å få tilgang.
Når en bruker er autentisert, må alle operasjoner utført av denne brukeren godkjennes. Det vil si at enkelte brukere kan få lov til å utføre visse oppgaver, mens andre ikke har det. Dette kalles autorisasjon.
Det anbefales at en sentralisert AAA-server distribueres for å håndheve AAA-basert påloggingsautentisering per bruker for NFVIS-tilgang. NFVIS støtter RADIUS- og TACACS-protokoller for å formidle nettverkstilgang. På AAA-serveren skal kun minimumstilgangsrettigheter gis til autentiserte brukere i henhold til deres spesifikke tilgangskrav. Dette reduserer eksponeringen for både ondsinnede og utilsiktede sikkerhetshendelser.
For mer informasjon om ekstern autentisering, se Konfigurere RADIUS og konfigurere en TACACS+-server.
Autentiseringsbuffer for ekstern autentiseringsserver
Funksjonsnavn
Utgivelsesinformasjon
Autentiseringsbuffer for ekstern NFVIS 4.5.1 Autentiseringsserver
Beskrivelse
Denne funksjonen støtter TACACS-autentisering gjennom OTP på NFVIS-portalen.
NFVIS-portalen bruker det samme One-Time Password (OTP) for alle API-kall etter den første autentiseringen. API-kallene mislykkes så snart OTP-en utløper. Denne funksjonen støtter TACACS OTP-autentisering med NFVIS-portalen.
Etter at du har autentisert deg gjennom TACACS-serveren ved hjelp av en OTP, oppretter NFVIS en hash-oppføring ved å bruke brukernavnet og OTP-en og lagrer denne hash-verdien lokalt. Denne lokalt lagrede hashverdien har
Sikkerhetshensyn 9
Rollebasert tilgangskontroll
Sikkerhetshensyn
en utløpstid stamp knyttet til det. Tiden stamp har samme verdi som tidsavbruddsverdien for SSH-økten, som er 15 minutter. Alle påfølgende autentiseringsforespørsler med samme brukernavn autentiseres mot denne lokale hash-verdien først. Hvis autentiseringen mislykkes med den lokale hashen, autentiserer NFVIS denne forespørselen med TACACS-serveren og oppretter en ny hash-oppføring når autentiseringen er vellykket. Hvis en hash-oppføring allerede eksisterer, er tiden stamp er tilbakestilt til 15 minutter.
Hvis du blir fjernet fra TACACS-serveren etter vellykket innlogging på portalen, kan du fortsette å bruke portalen til hash-oppføringen i NFVIS utløper.
Når du eksplisitt logger ut fra NFVIS-portalen eller er logget ut på grunn av inaktiv tid, kaller portalen et nytt API for å varsle NFVIS-backend om å tømme hash-oppføringen. Autentiseringsbufferen og alle dens oppføringer tømmes etter NFVIS omstart, fabrikkinnstilling eller oppgradering.
Rollebasert tilgangskontroll
Å begrense nettverkstilgang er viktig for organisasjoner som har mange ansatte, ansetter kontraktører eller tillater tilgang til tredjeparter, som kunder og leverandører. I et slikt scenario er det vanskelig å overvåke nettverkstilgang effektivt. I stedet er det bedre å kontrollere hva som er tilgjengelig, for å sikre sensitive data og kritiske applikasjoner.
Rollebasert tilgangskontroll (RBAC) er en metode for å begrense nettverkstilgang basert på rollene til individuelle brukere i en bedrift. RBAC lar brukere få tilgang til akkurat den informasjonen de trenger, og hindrer dem i å få tilgang til informasjon som ikke gjelder dem.
En ansatts rolle i bedriften bør brukes til å bestemme tillatelsene som er gitt, for å sikre at ansatte med lavere rettigheter ikke kan få tilgang til sensitiv informasjon eller utføre kritiske oppgaver.
Følgende brukerroller og privilegier er definert i NFVIS
Brukerrolle
Privilegium
Administratorer
Kan konfigurere alle tilgjengelige funksjoner og utføre alle oppgaver inkludert endring av brukerroller. Administratoren kan ikke slette grunnleggende infrastruktur som er grunnleggende for NFVIS. Admin-brukerens rolle kan ikke endres; det er alltid "administratorer".
Operatører
Kan starte og stoppe en VM, og view all informasjon.
Revisorer
De er de minst privilegerte brukerne. De har skrivebeskyttet tillatelse og kan derfor ikke endre noen konfigurasjon.
Fordeler med RBAC
Det er en rekke fordeler ved å bruke RBAC for å begrense unødvendig nettverkstilgang basert på folks roller i en organisasjon, inkludert:
· Forbedring av operasjonell effektivitet.
Å ha forhåndsdefinerte roller i RBAC gjør det enkelt å inkludere nye brukere med de riktige privilegiene eller bytte roller til eksisterende brukere. Det reduserer også muligheten for feil når brukertillatelser tildeles.
· Forbedre samsvar.
Sikkerhetshensyn 10
Sikkerhetshensyn
Rollebasert tilgangskontroll
Hver organisasjon må overholde lokale, statlige og føderale forskrifter. Companies generally prefer to implement RBAC systems to meet the regulatory and statutory requirements for confidentiality and privacy because executives and IT departments can more effectively manage how the data is accessed and used. Dette er spesielt viktig for finansinstitusjoner og helseforetak som administrerer sensitive data.
· Redusere kostnader. Ved å ikke gi brukertilgang til visse prosesser og applikasjoner, kan bedrifter spare eller bruke ressurser som nettverksbåndbredde, minne og lagring på en kostnadseffektiv måte.
· Reduserende risiko for brudd og datalekkasje. Implementering av RBAC betyr å begrense tilgangen til sensitiv informasjon, og dermed redusere potensialet for datainnbrudd eller datalekkasje.
Beste praksis for rollebaserte tilgangskontrollimplementeringer · Som administrator bestemmer du listen over brukere og tilordner brukerne til de forhåndsdefinerte rollene. For eksample, kan brukeren "nettverksadmin" opprettes og legges til i brukergruppen "administratorer".
konfigurer terminal rbac autentisering brukere opprette-brukernavn nettverksadministrator passord Test1_pass rolle administratorer commit
Merk Brukergruppene eller rollene opprettes av systemet. Du kan ikke opprette eller endre en brukergruppe. For å endre passordet, bruk kommandoen rbac authentication users user change-password i global konfigurasjonsmodus. For å endre brukerrollen, bruk kommandoen rbac authentication users user change-rolle i global konfigurasjonsmodus.
· Avslutte kontoer for brukere som ikke lenger trenger tilgang.
konfigurer terminal rbac-autentiseringsbrukere slett-brukernavn test1
· Gjennomfør regelmessig revisjoner for å evaluere rollene, de ansatte som er tildelt dem og tilgangen som er tillatt for hver rolle. Hvis en bruker viser seg å ha unødvendig tilgang til et bestemt system, endre brukerens rolle.
For mer informasjon, se Brukere, Roller og Autentisering
Granulær rollebasert tilgangskontroll Fra og med NFVIS 4.7.1 introduseres funksjonen Granulær rollebasert tilgangskontroll. Denne funksjonen legger til en ny ressursgruppepolicy som administrerer VM og VNF og lar deg tilordne brukere til en gruppe for å kontrollere VNF-tilgang under VNF-distribusjon. For mer informasjon, se Granulær rollebasert tilgangskontroll.
Sikkerhetshensyn 11
Begrens enhetens tilgjengelighet
Sikkerhetshensyn
Begrens enhetens tilgjengelighet
Brukere har gjentatte ganger blitt tatt uvitende av angrep mot funksjoner de ikke hadde beskyttet fordi de ikke visste at disse funksjonene var aktivert. Ubrukte tjenester har en tendens til å sitte igjen med standardkonfigurasjoner som ikke alltid er sikre. Disse tjenestene kan også bruke standardpassord. Noen tjenester kan gi en angriper enkel tilgang til informasjon om hva serveren kjører eller hvordan nettverket er satt opp. Følgende avsnitt beskriver hvordan NFVIS unngår slike sikkerhetsrisikoer:
Angrepsvektorreduksjon
Enhver programvare kan potensielt inneholde sikkerhetssårbarheter. Mer programvare betyr flere angrepsmuligheter. Selv om det ikke er noen offentlig kjente sårbarheter på tidspunktet for inkludering, vil sårbarheter sannsynligvis bli oppdaget eller avslørt i fremtiden. For å unngå slike scenarier, installeres bare de programvarepakkene som er avgjørende for NFVIS-funksjonaliteten. Dette bidrar til å begrense programvaresårbarheter, redusere ressursforbruket og redusere ekstraarbeid når det oppdages problemer med disse pakkene. All tredjepartsprogramvare inkludert i NFVIS er registrert i en sentral database i Cisco slik at Cisco er i stand til å utføre en organisert respons på selskapsnivå (Juridisk, Sikkerhet, etc.). Programvarepakker lappes med jevne mellomrom i hver utgivelse for kjente Common Vulnerabilities and Exposures (CVE-er).
Aktiverer bare viktige porter som standard
Bare de tjenestene som er absolutt nødvendige for å sette opp og administrere NFVIS er tilgjengelig som standard. Dette fjerner brukerinnsatsen som trengs for å konfigurere brannmurer og nekte tilgang til unødvendige tjenester. De eneste tjenestene som er aktivert som standard er oppført nedenfor sammen med portene de åpner.
Åpne port
Service
Beskrivelse
22/TCP
SSH
Secure Socket Shell for ekstern kommandolinjetilgang til NFVIS
80/TCP
HTTP
Hypertext Transfer Protocol for NFVIS-portaltilgangen. All HTTP-trafikk mottatt av NFVIS blir omdirigert til port 443 for HTTPS
443/TCP
HTTPS
Hypertext Transfer Protocol Secure for sikker NFVIS-portaltilgang
830/TCP
NETCONF-ssh
Port åpnet for Network Configuration Protocol (NETCONF) over SSH. NETCONF er en protokoll som brukes for automatisert konfigurasjon av NFVIS og for å motta asynkrone hendelsesvarsler fra NFVIS.
161/UDP
SNMP
Simple Network Management Protocol (SNMP). Brukes av NFVIS for å kommunisere med eksterne nettverksovervåkingsapplikasjoner. For mer informasjon se, Introduksjon om SNMP
Sikkerhetshensyn 12
Sikkerhetshensyn
Begrens tilgang til autoriserte nettverk for autoriserte tjenester
Begrens tilgang til autoriserte nettverk for autoriserte tjenester
Bare autoriserte opphavsmenn skal ha tillatelse til å forsøke tilgang til enhetsadministrasjon, og tilgang bør kun være til tjenestene de er autorisert til å bruke. NFVIS kan konfigureres slik at tilgang er begrenset til kjente, pålitelige kilder og forventet administrasjonstrafikkprofffiles. Dette reduserer risikoen for uautorisert tilgang og eksponering for andre angrep, for eksempel brute force, ordbok eller DoS-angrep.
For å beskytte NFVIS-administrasjonsgrensesnittene mot unødvendig og potensielt skadelig trafikk, kan en admin-bruker opprette tilgangskontrolllister (ACL) for nettverkstrafikken som mottas. Disse ACL-ene spesifiserer kilde-IP-adressene/-nettverkene som trafikken kommer fra, og typen trafikk som er tillatt eller avvist fra disse kildene. Disse IP-trafikkfiltrene brukes på hvert administrasjonsgrensesnitt på NFVIS. Følgende parametere er konfigurert i en tilgangskontrollliste for IP-mottak (ip-receive-acl)
Parameter
Verdi
Beskrivelse
Kildenettverk/nettmaske
Nettverk/nettmaske. For eksample: 0.0.0.0/0
172.39.162.0/24
Dette feltet spesifiserer IP-adressen/nettverket som trafikken kommer fra
Tjenestehandling
https icmp netconf scpd snmp ssh godta slipp avvise
Type trafikk fra den angitte kilden.
Handling som skal iverksettes på trafikken fra kildenettverket. Med aksept vil nye tilkoblingsforsøk bli gitt. Med avvisning vil tilkoblingsforsøk ikke bli akseptert. Hvis regelen er for en TCP-basert tjeneste som HTTPS, NETCONF, SCP, SSH, vil kilden få en TCP-reset (RST)-pakke. For ikke-TCP-regler som SNMP og ICMP, vil pakken bli droppet. Med drop vil alle pakker bli droppet umiddelbart, det er ingen informasjon sendt til kilden.
Sikkerhetshensyn 13
Privilegert feilsøkingstilgang
Sikkerhetshensyn
Parameterprioritet
Verdi En numerisk verdi
Beskrivelse
Prioriteten brukes til å håndheve et pålegg om reglene. Regler med høyere tallverdi for prioritet vil bli lagt til lenger ned i kjeden. Hvis du vil være sikker på at en regel legges til etter en annen, bruker du et lavprioritetsnummer for det første og et høyere prioritetsnummer for det følgende.
Følgende sample konfigurasjoner illustrerer noen scenarier som kan tilpasses for spesifikke brukstilfeller.
Konfigurering av ACL for IP-mottak
Jo mer restriktiv en ACL, desto mer begrenset er eksponeringen for uautoriserte tilgangsforsøk. En mer restriktiv ACL kan imidlertid skape administrasjonskostnader, og kan påvirke tilgjengeligheten for å utføre feilsøking. Følgelig er det en balanse å vurdere. Et kompromiss er å begrense tilgangen til kun bedriftens interne IP-adresser. Hver kunde må evaluere implementeringen av ACLer i forhold til sin egen sikkerhetspolicy, risiko, eksponering og aksept av disse.
Avvis ssh-trafikk fra et undernett:
nfvis(config)# systeminnstillinger ip-receive-acl 171.70.63.0/24 service ssh handling avvis prioritet 1
Fjerne tilgangskontrollister:
Når en oppføring slettes fra ip-receive-acl, slettes alle konfigurasjoner til den kilden siden kildens IP-adresse er nøkkelen. For å slette bare én tjeneste, konfigurer andre tjenester på nytt.
nfvis(config)# ingen systeminnstillinger ip-receive-acl 171.70.63.0/24
For mer informasjon, se Konfigurere IP-mottaks-ACL
Privilegert feilsøkingstilgang
Superbrukerkontoen på NFVIS er deaktivert som standard for å forhindre alle ubegrensede, potensielt negative, systemomfattende endringer, og NFVIS utsetter ikke systemskallet for brukeren.
Men for noen problemer som er vanskelige å feilsøke på NFVIS-systemet, kan Ciscos tekniske hjelpesenter-team (TAC) eller utviklingsteam kreve skalltilgang til kundens NFVIS. NFVIS har en sikker opplåsingsinfrastruktur for å sikre at privilegert feilsøkingstilgang til en enhet i felten er begrenset til autoriserte Cisco-ansatte. For å få sikker tilgang til Linux-skallet for denne typen interaktiv feilsøking, brukes en utfordring-respons-autentiseringsmekanisme mellom NFVIS og den interaktive feilsøkingsserveren som vedlikeholdes av Cisco. Admin-brukerens passord kreves også i tillegg til utfordring-svar-oppføringen for å sikre at enheten er tilgjengelig med kundens samtykke.
Trinn for å få tilgang til skallet for interaktiv feilsøking:
1. En admin-bruker starter denne prosedyren ved å bruke denne skjulte kommandoen.
nfvis# system shell-tilgang
Sikkerhetshensyn 14
Sikkerhetshensyn
Sikre grensesnitt
2. Skjermen vil vise en utfordringsstreng, for eksempelampde:
Utfordringsstreng (Vennligst kopier alt mellom stjernelinjene utelukkende):
******************************************************************************** SPH//wkAAABORlZJU0VOQ1M1NDA4L0s5AQAAABt+dcx+hB0V06r9RkdMMjEzNTgw RlHq7BxeAAA= DONE. ********************************************************************************
3. Cisco-medlemmet legger inn utfordringsstrengen på en interaktiv feilsøkingsserver som vedlikeholdes av Cisco. Denne serveren bekrefter at Cisco-brukeren er autorisert til å feilsøke NFVIS ved hjelp av skallet, og returnerer deretter en svarstreng.
4. Skriv inn svarstrengen på skjermen under denne ledeteksten: Skriv inn svaret ditt når du er klar:
5. Når du blir bedt om det, skal kunden skrive inn administratorpassordet. 6. Du får shell-tilgang hvis passordet er gyldig. 7. Utviklings- eller TAC-teamet bruker skallet for å fortsette med feilsøkingen. 8. For å avslutte shell-tilgang, skriv Exit.
Sikre grensesnitt
NFVIS-administrasjonstilgang er tillatt ved bruk av grensesnittene vist i diagrammet. De følgende avsnittene beskriver beste praksis for sikkerhet for disse grensesnittene til NFVIS.
Konsoll SSH
Konsollporten er en asynkron seriell port som lar deg koble til NFVIS CLI for innledende konfigurasjon. En bruker kan få tilgang til konsollen med enten fysisk tilgang til NFVIS eller ekstern tilgang gjennom bruk av en terminalserver. Hvis konsollporttilgang er nødvendig via en terminalserver, konfigurer tilgangslister på terminalserveren for å tillate tilgang kun fra de nødvendige kildeadressene.
Brukere kan få tilgang til NFVIS CLI ved å bruke SSH som en sikker måte for ekstern pålogging. Integriteten og konfidensialiteten til NFVIS-administrasjonstrafikken er avgjørende for sikkerheten til det administrerte nettverket siden administrasjonsprotokoller ofte inneholder informasjon som kan brukes til å penetrere eller forstyrre nettverket.
Sikkerhetshensyn 15
Tidsavbrudd for CLI økt
Sikkerhetshensyn
NFVIS bruker SSH versjon 2, som er Ciscos og Internetts de facto standardprotokoll for interaktive pålogginger og støtter sterk kryptering, hash og nøkkelutvekslingsalgoritmer anbefalt av Security and Trust Organization i Cisco.
Tidsavbrudd for CLI økt
Ved å logge inn via SSH etablerer en bruker en økt med NFVIS. While the user is logged in, if the user leaves the logged-in session unattended, this can expose the network to a security risk. Session security limits the risk of internal attacks, such as one user trying to use another user's session.
For å redusere denne risikoen, tar NFVIS timeout CLI-økter etter 15 minutter med inaktivitet. Når tidsavbruddet for økten er nådd, logges brukeren automatisk av.
NETCONF
Network Configuration Protocol (NETCONF) er en nettverksadministrasjonsprotokoll utviklet og standardisert av IETF for automatisert konfigurasjon av nettverksenheter.
NETCONF-protokollen bruker en Extensible Markup Language (XML)-basert datakoding for konfigurasjonsdataene så vel som protokollmeldingene. Protokollmeldingene utveksles på toppen av en sikker transportprotokoll.
NETCONF lar NFVIS avsløre et XML-basert API som nettverksoperatøren kan bruke til å sette og få konfigurasjonsdata og hendelsesvarsler sikkert over SSH.
For mer informasjon se NETCONF hendelsesvarsler.
REST API
NFVIS kan konfigureres ved hjelp av RESTful API over HTTPS. REST API lar de forespørrende systemene få tilgang til og manipulere NFVIS-konfigurasjonen ved å bruke et enhetlig og forhåndsdefinert sett med statsløse operasjoner. Detaljer om alle REST API-ene finner du i NFVIS API Reference Guide.
Når brukeren utsteder en REST API, etableres en økt med NFVIS. For å begrense risiko knyttet til tjenestenektangrep, begrenser NFVIS det totale antallet samtidige REST-økter til 100.
NFVIS Web Portal
NFVIS-portalen er en web-basert grafisk brukergrensesnitt som viser informasjon om NFVIS. Portalen gir brukeren en enkel måte å konfigurere og overvåke NFVIS over HTTPS uten å måtte kjenne til NFVIS CLI og API.
Sesjonsledelse
Den statsløse naturen til HTTP og HTTPS krever en metode for unik sporing av brukere gjennom bruk av unike økt-IDer og informasjonskapsler.
NFVIS krypterer brukerens økt. AES-256-CBC-chifferet brukes til å kryptere øktinnholdet med en HMAC-SHA-256-autentisering tag. En tilfeldig 128-bits initialiseringsvektor genereres for hver krypteringsoperasjon.
En revisjonspost startes når en portaløkt opprettes. Sesjonsinformasjon slettes når brukeren logger av eller når økten blir tidsavbrutt.
Standard tidsavbrudd for inaktivitet for portaløkter er 15 minutter. Dette kan imidlertid konfigureres for gjeldende økt til en verdi mellom 5 og 60 minutter på Innstillinger-siden. Automatisk utlogging vil bli initiert etter dette
Sikkerhetshensyn 16
Sikkerhetshensyn
HTTPS
HTTPS
periode. Flere økter er ikke tillatt i en enkelt nettleser. Maksimalt antall samtidige økter er satt til 30. NFVIS-portalen bruker informasjonskapsler for å knytte data til brukeren. Den bruker følgende informasjonskapselegenskaper for økt sikkerhet:
· kortvarig for å sikre at informasjonskapselen utløper når nettleseren lukkes · httpBare for å gjøre informasjonskapselen utilgjengelig fra JavaScript · secureProxy for å sikre at informasjonskapselen kun kan sendes over SSL.
Selv etter autentisering er angrep som Cross-Site Request Forgery (CSRF) mulig. I dette scenariet kan en sluttbruker utilsiktet utføre uønskede handlinger på en web applikasjon der de for øyeblikket er autentisert. For å forhindre dette bruker NFVIS CSRF-tokens for å validere hver REST API som påkalles under hver økt.
URL Omdirigering i typisk web servere, når en side ikke finnes på web server, får brukeren en 404-melding; for sider som finnes, får de en påloggingsside. Sikkerhetseffekten av dette er at en angriper kan utføre en brute force-skanning og enkelt oppdage hvilke sider og mapper som finnes. For å forhindre dette på NFVIS, alt ikke-eksisterende URLs prefiks med enhetens IP blir omdirigert til portalpåloggingssiden med en 301-statussvarkode. Dette betyr at uavhengig av URL forespurt av en angriper, vil de alltid få påloggingssiden for å autentisere seg. Alle HTTP-serverforespørsler omdirigeres til HTTPS og har følgende overskrifter konfigurert:
· X-Content-Type-Options · X-XSS-Protection · Content-Security-Policy · X-Frame-Options · Strict-Transport-Security · Cache-Control
Deaktivere portalen NFVIS-portaltilgangen er aktivert som standard. Hvis du ikke planlegger å bruke portalen, anbefales det å deaktivere portaltilgangen ved å bruke denne kommandoen:
Konfigurer terminal Systemportaltilgang deaktivert commit
Alle HTTPS-dataene til og fra NFVIS bruker Transport Layer Security (TLS) for å kommunisere på tvers av nettverket. TLS er etterfølgeren til Secure Socket Layer (SSL).
Sikkerhetshensyn 17
HTTPS
Sikkerhetshensyn
TLS-håndtrykket involverer autentisering der klienten bekrefter serverens SSL-sertifikat med sertifiseringsmyndigheten som utstedte det. Dette bekrefter at serveren er den den sier den er, og at klienten samhandler med eieren av domenet. Som standard bruker NFVIS et selvsignert sertifikat for å bevise sin identitet overfor sine klienter. Dette sertifikatet har en 2048-bits offentlig nøkkel for å øke sikkerheten til TLS-krypteringen, siden krypteringsstyrken er direkte relatert til nøkkelstørrelsen.
Sertifikatbehandling NFVIS genererer et selvsignert SSL-sertifikat når det først installeres. Det er en beste praksis for sikkerhet å erstatte dette sertifikatet med et gyldig sertifikat signert av en kompatibel sertifiseringsinstans (CA). Bruk følgende trinn for å erstatte standard selvsignert sertifikat: 1. Generer en forespørsel om sertifikatsignering (CSR) på NFVIS.
En forespørsel om sertifikatsignering (CSR) er en file med en blokk med kodet tekst som gis til en sertifiseringsinstans når du søker om et SSL-sertifikat. Dette file contains information that should be included in the certificate such as the organization name, common name (domain name), locality, and country. De file inneholder også den offentlige nøkkelen som skal inkluderes i sertifikatet. NFVIS bruker en 2048-bits offentlig nøkkel siden krypteringsstyrken er høyere med en høyere nøkkelstørrelse. For å generere en CSR på NFVIS, kjør følgende kommando:
nfvis# system sertifikat signering-forespørsel [common-name country-code locality organization organization-unit-name state] CSR file er lagret som /data/intdatastore/download/nfvis.csr. . 2. Få et SSL-sertifikat fra en CA ved å bruke CSR. Fra en ekstern vert, bruk scp-kommandoen for å laste ned forespørselen om sertifikatsignering.
[myhost:/tmp] > scp -P 22222 admin@ :/data/intdatastore/download/nfvis.csrfile-navn>
Kontakt en sertifiseringsinstans for å utstede et nytt SSL-serversertifikat ved hjelp av denne CSR. 3. Installer CA Signed Certificate.
Fra en ekstern server, bruk scp-kommandoen for å laste opp sertifikatet file inn i NFVIS til data/intdatastore/uploads/ katalog.
[myhost:/tmp] > scp -P 22222 file> admin@ :/data/intdatastore/opplastinger
Installer sertifikatet i NFVIS ved å bruke følgende kommando.
nfvis# systemsertifikat install-sert-bane file:///data/intdatastore/uploads/<certificate file>
4. Bytt til å bruke CA-signert sertifikat. Bruk følgende kommando for å begynne å bruke det CA-signerte sertifikatet i stedet for standard selvsignert sertifikat.
Sikkerhetshensyn 18
Sikkerhetshensyn
SNMP-tilgang
nfvis(config)# systemsertifikat use-cert cert-type ca-signert
SNMP-tilgang
Simple Network Management Protocol (SNMP) er en Internett-standardprotokoll for innsamling og organisering av informasjon om administrerte enheter på IP-nettverk, og for å endre denne informasjonen for å endre enhetsatferd.
Tre betydelige versjoner av SNMP er utviklet. NFVIS støtter SNMP versjon 1, versjon 2c og versjon 3. SNMP versjon 1 og 2 bruker fellesskapsstrenger for autentisering, og disse sendes i ren tekst. Så det er en beste praksis for sikkerhet å bruke SNMP v3 i stedet.
SNMPv3 gir sikker tilgang til enheter ved å bruke tre aspekter: – brukere, autentisering og kryptering. SNMPv3 bruker USM (User-based Security Module) for å kontrollere tilgang til informasjon tilgjengelig via SNMP. SNMP v3-brukeren er konfigurert med en autentiseringstype, en personverntype samt en passordfrase. Alle brukere som deler en gruppe bruker samme SNMP-versjon, men de spesifikke sikkerhetsnivåinnstillingene (passord, krypteringstype osv.) er spesifisert per bruker.
Tabellen nedenfor oppsummerer sikkerhetsalternativene i SNMP
Modell
Nivå
Autentisering
Encypsjon
Utfall
v1
noAuthNoPriv
Fellesskapsstreng nr
Bruker et fellesskap
strengkamp for
autentisering.
v2c
noAuthNoPriv
Fellesskapsstreng nr
Bruker et fellesskapsstrengmatch for autentisering.
v3
noAuthNoPriv
Brukernavn
Ingen
Bruker et brukernavn
kamp for
autentisering.
v3
authNoPriv
Message Digest 5 No
Gir
(MD5)
autentiseringsbasert
or
på HMAC-MD5-96 eller
Sikker Hash
HMAC-SHA-96
Algoritme (SHA)
algoritmer.
Sikkerhetshensyn 19
Bannere for juridiske meldinger
Sikkerhetshensyn
Modell v3
Nivå authPriv
Autentisering MD5 eller SHA
Encypsjon
Utfall
Datakryptering gir
Standard (DES) eller autentiseringsbasert
Avansert
på
Krypteringsstandard HMAC-MD5-96 eller
(AES)
HMAC-SHA-96
algoritmer.
Tilbyr DES-krypteringsalgoritme i chifferblokkkjedemodus (CBC-DES)
or
AES-krypteringsalgoritme brukt i Cipher FeedBack Mode (CFB), med en 128-bits nøkkelstørrelse (CFB128-AES-128)
Siden den ble tatt i bruk av NIST, har AES blitt den dominerende krypteringsalgoritmen i hele bransjen. For å følge industriens migrering bort fra MD5 og mot SHA, er det en beste praksis for sikkerhet å konfigurere SNMP v3-autentiseringsprotokollen som SHA og personvernprotokollen som AES.
For mer informasjon om SNMP, se Introduksjon om SNMP
Bannere for juridiske meldinger
Det anbefales at et juridisk varslingsbanner finnes på alle interaktive økter for å sikre at brukere blir varslet om sikkerhetspolicyen som håndheves og som de er underlagt. I noen jurisdiksjoner er sivil og/eller straffeforfølgelse av en angriper som bryter seg inn i et system lettere, eller til og med nødvendig, hvis et juridisk varslingsbanner presenteres, som informerer uautoriserte brukere om at bruken deres faktisk er uautorisert. I noen jurisdiksjoner kan det også være forbudt å overvåke aktiviteten til en uautorisert bruker med mindre de har blitt varslet om intensjonen om å gjøre det.
Juridiske varslingskrav er komplekse og varierer i hver jurisdiksjon og situasjon. Selv innenfor jurisdiksjoner varierer juridiske meninger. Diskuter dette problemet med din egen juridiske rådgiver for å sikre at varslingsbanneret oppfyller selskapets, lokale og internasjonale juridiske krav. Dette er ofte avgjørende for å sikre passende tiltak i tilfelle et sikkerhetsbrudd. I samarbeid med selskapets juridiske rådgiver inkluderer uttalelser som kan være inkludert i et juridisk varslingsbanner:
· Varsling om at systemets tilgang og bruk kun er tillatt av spesifikt autorisert personell, og kanskje informasjon om hvem som kan autorisere bruk.
· Varsling om at uautorisert tilgang og bruk av systemet er ulovlig, og kan bli underlagt sivile og/eller strafferettslige straffer.
· Varsling om at tilgang og bruk av systemet kan logges eller overvåkes uten ytterligere varsel, og de resulterende loggene kan brukes som bevis i retten.
· Ytterligere spesifikke merknader som kreves av spesifikke lokale lover.
Sikkerhetshensyn 20
Sikkerhetshensyn
Fabrikkinnstilling
Fra et sikkerhet snarere enn et juridisk synspunkt view, skal et banner med juridiske meldinger ikke inneholde spesifikk informasjon om enheten, for eksempel dens navn, modell, programvare, plassering, operatør eller eier fordi denne typen informasjon kan være nyttig for en angriper.
Følgende er somampet banner for juridisk melding som kan vises før pålogging:
UAUTORISERT TILGANG TIL DENNE ENHETEN ER FORBUDT Du må ha eksplisitt, autorisert tillatelse for å få tilgang til eller konfigurere denne enheten. Uautoriserte forsøk og handlinger for å få tilgang til eller bruke
dette systemet kan resultere i sivile og/eller strafferettslige straffer. Alle aktiviteter som utføres på denne enheten logges og overvåkes
Merk Presenter et juridisk varslingsbanner godkjent av selskapets juridiske rådgiver.
NFVIS allows the configuration of a banner and Message of the Day (MOTD). The banner is displayed before the user logs in. Once the user logs in to NFVIS, a system-defined banner provides Copyright information about NFVIS, and the message-of-the-day (MOTD), if configured, will appear, followed by kommandolinjeledeteksten eller portalen view, avhengig av påloggingsmetoden.
Det anbefales at et påloggingsbanner implementeres for å sikre at et juridisk varslingsbanner presenteres på alle enhetsadministrasjonstilgangsøktene før en påloggingsforespørsel presenteres. Bruk denne kommandoen til å konfigurere banneret og MOTD.
nfvis(config)# banner-motd banner motd
For mer informasjon om bannerkommandoen, se Konfigurer banner, Dagens melding og systemtid.
Fabrikkinnstilling
Factory Reset fjerner alle kundespesifikke data som har blitt lagt til enheten siden leveringstidspunktet. Dataene som slettes inkluderer konfigurasjoner, logg files, VM-bilder, tilkoblingsinformasjon og brukerpåloggingsinformasjon.
Den gir én kommando for å tilbakestille enheten til de opprinnelige fabrikkinnstillingene, og er nyttig i følgende scenarier:
· Return Material Authorization (RMA) for en enhet – Hvis du må returnere en enhet til Cisco for RMA, bruk fabrikkinnstilling for å fjerne alle kundespesifikke data.
· Gjenopprette en kompromittert enhet – Hvis nøkkelmaterialet eller legitimasjonen som er lagret på en enhet er kompromittert, tilbakestill enheten til fabrikkkonfigurasjon og konfigurer deretter enheten på nytt.
· Hvis den samme enheten må gjenbrukes på et annet sted med en ny konfigurasjon, utfør en tilbakestilling av fabrikkstandard for å fjerne den eksisterende konfigurasjonen og bringe den til en ren tilstand.
NFVIS gir følgende alternativer innen fabrikkinnstilling:
Alternativ for tilbakestilling av fabrikk
Data slettet
Data beholdt
alle
All konfigurasjon, opplastet bilde Administratorkontoen beholdes og
files, VM-er og logger.
passordet vil bli endret til
Tilkobling til enheten vil være fabrikkstandardpassord.
tapt.
Sikkerhetshensyn 21
Infrastrukturstyringsnettverk
Sikkerhetshensyn
Fabrikkinnstillingsalternativ alle-unntatt-bilder
alt-unntatt-bilder-tilkobling
produksjon
Data slettet
Data beholdt
All konfigurasjon unntatt bilde Bildekonfigurasjon, registrert
konfigurasjon, VM-er og opplastede bilder og logger
bilde files.
Administrasjonskontoen beholdes og
Tilkobling til enheten vil være passordet vil bli endret til
tapt.
standard fabrikkpassord.
All konfigurasjon unntatt bilde, bilder, nettverk og tilkobling
nettverk og tilkobling
relatert konfigurasjon, registrert
konfigurasjon, VM-er og opplastede bilder og logger.
bilde files.
Administrasjonskontoen beholdes og
Tilkobling til enheten er
den tidligere konfigurerte administratoren
tilgjengelig.
passord vil bli bevart.
All konfigurasjon unntatt bildekonfigurasjon, VM-er, opplastet bilde files, og logger.
Tilkoblingen til enheten vil gå tapt.
Bilderelatert konfigurasjon og registrerte bilder
Administratorkontoen beholdes og passordet vil bli endret til fabrikkstandardpassordet.
Brukeren må velge riktig alternativ nøye basert på formålet med tilbakestillingen til fabrikkstandard. For mer informasjon, se Tilbakestille til fabrikkstandard.
Infrastrukturstyringsnettverk
Et infrastrukturadministrasjonsnettverk refererer til nettverket som bærer kontroll- og administrasjonsplantrafikken (som NTP, SSH, SNMP, syslog, etc.) for infrastrukturenhetene. Enhetstilgang kan skje via konsollen, så vel som via Ethernet-grensesnittene. Denne kontroll- og administrasjonsplantrafikken er avgjørende for nettverksoperasjoner, og gir innsyn i og kontroll over nettverket. Følgelig er et godt utformet og sikkert infrastrukturadministrasjonsnettverk avgjørende for den generelle sikkerheten og driften av et nettverk. En av de viktigste anbefalingene for et sikkert infrastrukturadministrasjonsnettverk er separering av administrasjon og datatrafikk for å sikre ekstern administrering selv under høy belastning og høye trafikkforhold. Dette kan oppnås ved hjelp av et dedikert administrasjonsgrensesnitt.
Følgende er tilnærmingene til implementering av infrastrukturadministrasjonsnettverk:
Ledelse utenfor båndet
Et Out-of-band Management (OOB) administrasjonsnettverk består av et nettverk som er fullstendig uavhengig og fysisk adskilt fra datanettverket som det hjelper med å administrere. Dette blir også noen ganger referert til som et datakommunikasjonsnettverk (DCN). Nettverksenheter kan koble til OOB-nettverket på forskjellige måter: NFVIS støtter et innebygd administrasjonsgrensesnitt som kan brukes til å koble til OOB-nettverket. NFVIS tillater konfigurering av et forhåndsdefinert fysisk grensesnitt, MGMT-porten på ENCS, som et dedikert administrasjonsgrensesnitt. Å begrense administrasjonspakker til angitte grensesnitt gir større kontroll over administrasjonen av en enhet, og gir dermed mer sikkerhet for den enheten. Andre fordeler inkluderer forbedret ytelse for datapakker på ikke-administrasjonsgrensesnitt, støtte for nettverksskalerbarhet,
Sikkerhetshensyn 22
Sikkerhetshensyn
Pseudo-out-of-band Management
behov for færre tilgangskontrolllister (ACL-er) for å begrense tilgangen til en enhet, og hindre at administrasjonspakkeflommer når CPU-en. Network devices can also connect to the OOB network via dedicated data interfaces. In this case, ACLs should be deployed to ensure that management traffic is only handled by the dedicated interfaces. For further information, see Configuring the IP Receive ACL and Port 22222 and Management Interface ACL.
Pseudo-out-of-band Management
Et pseudo-out-of-band-administrasjonsnettverk bruker den samme fysiske infrastrukturen som datanettverket, men gir logisk separasjon gjennom virtuell separasjon av trafikk, ved å bruke VLAN. NFVIS støtter oppretting av VLAN-er og virtuelle broer for å hjelpe til med å identifisere forskjellige trafikkkilder og separere trafikk mellom VM-er. Å ha separate broer og VLAN-er isolerer det virtuelle maskinnettverkets datatrafikk og administrasjonsnettverket, og gir dermed trafikksegmentering mellom VM-ene og verten. For mer informasjon se Konfigurere VLAN for NFVIS Management Traffic.
In-band Management
Et in-band administrasjonsnettverk bruker de samme fysiske og logiske banene som datatrafikken. Til syvende og sist krever dette nettverksdesignet en per-kunde-analyse av risiko kontra fordeler og kostnader. Noen generelle betraktninger inkluderer:
· Et isolert OOB-administrasjonsnettverk maksimerer synlighet og kontroll over nettverket selv under forstyrrende hendelser.
· Overføring av nettverkstelemetri over et OOB-nettverk minimerer sjansen for forstyrrelse av selve informasjonen som gir kritisk nettverkssynlighet.
· In-band administrasjonstilgang til nettverksinfrastruktur, verter osv. er sårbar for fullstendig tap i tilfelle en nettverkshendelse, noe som fjerner all nettverkssynlighet og kontroll. Passende QoS-kontroller bør settes på plass for å redusere denne forekomsten.
· NFVIS har grensesnitt som er dedikert til enhetsadministrasjon, inkludert serielle konsollporter og Ethernet-administrasjonsgrensesnitt.
· Et OOB-administrasjonsnettverk kan vanligvis distribueres til en rimelig pris, siden administrasjonsnettverkstrafikk vanligvis ikke krever høy båndbredde eller høyytelsesenheter, og bare krever tilstrekkelig porttetthet for å støtte tilkoblingen til hver infrastrukturenhet.
Beskyttelse av lokalt lagret informasjon
Beskyttelse av sensitiv informasjon
NFVIS lagrer noe sensitiv informasjon lokalt, inkludert passord og hemmeligheter. Passord bør generelt vedlikeholdes og kontrolleres av en sentralisert AAA-server. However, even if a centralized AAA server is deployed, some locally-stored passwords are required for certain cases such as local fallback in the case of AAA servers not being available, special-use usernames, etc. These local passwords and other sensitive
Sikkerhetshensyn 23
File Overføre
Sikkerhetshensyn
informasjon lagres på NFVIS som hashes slik at det ikke er mulig å gjenopprette den originale legitimasjonen fra systemet. Hashing er en allment akseptert bransjenorm.
File Overføre
Files som kanskje må overføres til NFVIS-enheter inkluderer VM-bilde og NFVIS-oppgradering files. Den sikre overføringen av files er kritisk for nettverksinfrastruktursikkerhet. NFVIS støtter Secure Copy (SCP) for å sikre sikkerheten til file overføre. SCP er avhengig av SSH for sikker autentisering og transport, som muliggjør sikker og autentisert kopiering av files.
En sikker kopi fra NFVIS initieres gjennom scp-kommandoen. Kommandoen sikker kopi (scp) lar bare administratorbrukeren kopiere sikkert files fra NFVIS til et eksternt system, eller fra et eksternt system til NFVIS.
Syntaksen for scp-kommandoen er:
scp
Vi bruker port 22222 for NFVIS SCP-serveren. Som standard er denne porten stengt og brukere kan ikke sikre kopiering files inn i NFVIS fra en ekstern klient. Hvis det er behov for å SCP a file fra en ekstern klient kan brukeren åpne porten ved å bruke:
systeminnstillinger ip-receive-acl (adresse)/(maskelengde) tjeneste scpd prioritet (nummer) handling godta
begå
For å hindre brukere fra å få tilgang til systemkataloger, kan sikker kopiering kun utføres til eller fra intdatastore:, extdatastore1:, extdatastore2:, usb: og nfs:, hvis tilgjengelig. Sikker kopiering kan også utføres fra logger: og teknisk support:
Logging
NFVIS access and configuration changes are logged as audit logs to record the following information: · Who accessed the device · When did a user log in · What did a user do in terms of the host configuration and the VM lifecycle · When did a user log av · Mislykkede tilgangsforsøk · Mislykkede autentiseringsforespørsler · Mislykkede autorisasjonsforespørsler
Denne informasjonen er uvurderlig for rettsmedisinske analyser i tilfelle uautoriserte forsøk eller tilgang, så vel som for konfigurasjonsendringsproblemer og for å hjelpe til med å planlegge gruppeadministrasjonsendringer. Det kan også brukes sanntid til å identifisere unormale aktiviteter som kan indikere at et angrep finner sted. Denne analysen kan korreleres med informasjon fra flere eksterne kilder, for eksempel IDS og brannmurlogger.
Sikkerhetshensyn 24
Sikkerhetshensyn
Virtual Machine sikkerhet
Alle nøkkelhendelsene på NFVIS sendes som hendelsesvarsler til NETCONF-abonnenter og som syslogger til de konfigurerte sentrale loggingsserverne. For mer informasjon om syslog-meldinger og hendelsesvarsler, se vedlegg.
Virtual Machine sikkerhet
Denne delen beskriver sikkerhetsfunksjoner knyttet til registrering, distribusjon og drift av virtuelle maskiner på NFVIS.
VNF sikker oppstart
NFVIS støtter Open Virtual Machine Firmware (OVMF) for å aktivere UEFI sikker oppstart for virtuelle maskiner som støtter sikker oppstart. VNF Secure boot verifies that each layer of the VM boot software is signed, including the bootloader, the operating system kernel, and operating system drivers.
For mer informasjon se Secure Boot of VNFs.
VNC-konsolltilgangsbeskyttelse
NFVIS lar brukeren opprette en Virtual Network Computing (VNC) sesjon for å få tilgang til en distribuert VMs eksterne skrivebord. For å aktivere dette åpner NFVIS dynamisk en port som brukeren kan koble til ved hjelp av deres web nettleser. Denne porten blir bare stående åpen i 60 sekunder for en ekstern server å starte en økt til VM. Hvis ingen aktivitet er sett innen denne tiden, er havnen stengt. Portnummeret tildeles dynamisk og tillater dermed kun en engangstilgang til VNC-konsollen.
nfvis# vncconsole start deployment-name 1510614035 vm-name ROUTER vncconsole-url :6005/vnc_auto.html
Peker nettleseren til https:// :6005/vnc_auto.html vil koble til ROUTER VMs VNC-konsoll.
Sikkerhetshensyn 25
Krypterte VM-konfigurasjonsdatavariabler
Sikkerhetshensyn
Krypterte VM-konfigurasjonsdatavariabler
Under VM-distribusjon gir brukeren en dag-0-konfigurasjon file for VM. Dette file kan inneholde sensitiv informasjon som passord og nøkler. Hvis denne informasjonen sendes som klartekst, vises den i loggen files og interne databaseposter i klartekst. Denne funksjonen lar brukeren flagge en konfigurasjonsdatavariabel som sensitiv slik at verdien krypteres med AES-CFB-128-kryptering før den lagres eller sendes til interne undersystemer.
For mer informasjon se VM Deployment Parameters.
Kontrollsumverifisering for ekstern bilderegistrering
For å registrere et eksternt lokalisert VNF-bilde, spesifiserer brukeren plasseringen. Bildet må lastes ned fra en ekstern kilde, for eksempel en NFS-server eller en ekstern HTTPS-server.
For å vite om en lastet ned file er trygt å installere, er det viktig å sammenligne filesin kontrollsum før du bruker den. Å verifisere sjekksummen bidrar til å sikre at file ble ikke ødelagt under nettverksoverføring, eller modifisert av en ondsinnet tredjepart før du lastet den ned.
NFVIS støtter sjekksum- og sjekksum_algoritme-alternativene for brukeren for å gi den forventede sjekksum- og sjekksumalgoritmen (SHA256 eller SHA512) som skal brukes til å verifisere sjekksummen til det nedlastede bildet. Bildeoppretting mislykkes hvis kontrollsummen ikke stemmer.
Sertifiseringsvalidering for ekstern bilderegistrering
For å registrere et VNF-bilde på en HTTPS-server, må bildet lastes ned fra den eksterne HTTPS-serveren. For å laste ned dette bildet på en sikker måte, verifiserer NFVIS SSL-sertifikatet til serveren. Brukeren må spesifisere enten banen til sertifikatet file eller PEM-formatsertifikatets innhold for å aktivere denne sikre nedlastingen.
Flere detaljer finner du i avsnittet om sertifikatvalidering for bilderegistrering
VM-isolering og ressursklargjøring
Network Function Virtualization (NFV)-arkitekturen består av:
· Virtualiserte nettverksfunksjoner (VNF-er), som er virtuelle maskiner som kjører programvareapplikasjoner som leverer nettverksfunksjonalitet som en ruter, brannmur, lastbalansering og så videre.
· Nettverksfunksjoner virtualiseringsinfrastruktur, som består av infrastrukturkomponentene – databehandling, minne, lagring og nettverk, på en plattform som støtter nødvendig programvare og hypervisor.
Med NFV virtualiseres nettverksfunksjoner slik at flere funksjoner kan kjøres på en enkelt server. Som et resultat er mindre fysisk maskinvare nødvendig, noe som muliggjør ressurskonsolidering. I dette miljøet er det viktig å simulere dedikerte ressurser for flere VNF-er fra et enkelt fysisk maskinvaresystem. Ved å bruke NFVIS kan VM-er distribueres på en kontrollert måte slik at hver VM mottar ressursene den trenger. Ressurser deles etter behov fra det fysiske miljøet til de mange virtuelle miljøene. De individuelle VM-domenene er isolert slik at de er separate, distinkte og sikre miljøer, som ikke kjemper med hverandre om delte ressurser.
VM-er kan ikke bruke flere ressurser enn klargjort. Dette unngår en tjenestenekt-tilstand fra én VM som bruker ressursene. Som et resultat er CPU, minne, nettverk og lagring beskyttet.
Sikkerhetshensyn 26
Sikkerhetshensyn
CPU-isolasjon
CPU-isolasjon
NFVIS-systemet reserverer kjerner for infrastrukturprogramvaren som kjører på verten. Resten av kjernene er tilgjengelige for VM-distribusjon. Dette garanterer at VM-ens ytelse ikke påvirker NFVIS-vertytelsen. VM-er med lav latens NFVIS tildeler eksplisitt dedikerte kjerner til VM-er med lav latens som er distribuert på den. Hvis VM krever 2 vCPUer, tildeles den 2 dedikerte kjerner. Dette forhindrer deling og overabonnement av kjerner og garanterer ytelsen til VM-ene med lav latens. Hvis antallet tilgjengelige kjerner er mindre enn antallet vCPUer som er forespurt av en annen VM med lav latens, forhindres distribusjonen siden vi ikke har tilstrekkelige ressurser. VM-er som ikke har lav latens NFVIS tildeler delbare prosessorer til VM-er som ikke har lav latens. Hvis VM krever 2 vCPUer, er den tildelt 2 CPUer. Disse 2 CPU-ene kan deles mellom andre VM-er som ikke har lav latens. Hvis antallet tilgjengelige CPUer er mindre enn antallet vCPUer som er forespurt av en annen VM uten lav latens, er distribusjonen fortsatt tillatt fordi denne VM vil dele CPU med eksisterende VMer med ikke lav latens.
Minnetildeling
NFVIS-infrastrukturen krever en viss mengde minne. When a VM is deployed, there is a check to ensure that the memory available after reserving the memory required for the infrastructure and previously deployed VMs, is sufficient for the new VM. Vi tillater ikke minneoverabonnement for VM-ene.
Sikkerhetshensyn 27
Lagringsisolering
VM-er har ikke rett til å få direkte tilgang til verten file system og lagring.
Lagringsisolering
Sikkerhetshensyn
ENCS-plattformen støtter et internt datalager (M2 SSD) og eksterne disker. NFVIS er installert på det interne datalageret. VNF-er kan også distribueres på dette interne datalageret. Det er en beste praksis for sikkerhet å lagre kundedata og distribuere virtuelle maskiner for kundeapplikasjoner på de eksterne diskene. Å ha fysisk separate disker for systemet files vs applikasjonen files bidrar til å beskytte systemdata mot korrupsjon og sikkerhetsproblemer.
·
Grensesnittisolasjon
Single Root I/O Virtualization eller SR-IOV er en spesifikasjon som tillater isolering av PCI Express (PCIe) ressurser som en Ethernet-port. Ved å bruke SR-IOV kan en enkelt Ethernet-port vises som flere, separate, fysiske enheter kjent som virtuelle funksjoner. Alle VF-enhetene på den adapteren deler den samme fysiske nettverksporten. En gjest kan bruke en eller flere av disse virtuelle funksjonene. En virtuell funksjon vises for gjesten som et nettverkskort, på samme måte som et vanlig nettverkskort vil fremstå for et operativsystem. Virtuelle funksjoner har nesten opprinnelig ytelse og gir bedre ytelse enn para-virtualiserte drivere og emulert tilgang. Virtuelle funksjoner gir databeskyttelse mellom gjester på samme fysiske server da dataene administreres og kontrolleres av maskinvaren. NFVIS VNF-er kan bruke SR-IOV-nettverk for å koble til WAN- og LAN-bakplanporter.
Sikkerhetshensyn 28
Sikkerhetshensyn
Sikker utviklingslivssyklus
Hver slik VM eier et virtuelt grensesnitt og tilhørende ressurser for å oppnå databeskyttelse blant VM-er.
Sikker utviklingslivssyklus
NFVIS følger en sikker utviklingslivssyklus (SDL) for programvare. Dette er en repeterbar, målbar prosess designet for å redusere sårbarheter og forbedre sikkerheten og motstandskraften til Cisco-løsninger. Cisco SDL bruker bransjeledende praksis og teknologi for å bygge pålitelige løsninger som har færre felt-oppdagede produktsikkerhetshendelser. Hver NFVIS-utgivelse går gjennom følgende prosesser.
· Følger Cisco-interne og markedsbaserte produktsikkerhetskrav · Registrering av tredjepartsprogramvare med et sentralt arkiv hos Cisco for sårbarhetssporing · Periodisk oppdatering av programvare med kjente rettelser for CVEer. · Utforme programvare med sikkerhet i tankene · Følge sikker kodingspraksis som å bruke kontrollerte vanlige sikkerhetsmoduler som CiscoSSL, kjører
Statisk analyse og implementering av inputvalidering for å forhindre kommandoinjeksjon osv. · Bruke Application Security-verktøy som IBM AppScan, Nessus og andre interne Cisco-verktøy.
Sikkerhetshensyn 29
Sikker utviklingslivssyklus
Sikkerhetshensyn
Sikkerhetshensyn 30
Dokumenter / Ressurser
 |
CISCO Enterprise Network Function Virtualization Infrastructure Software [pdfBrukerhåndbok Enterprise Network Function Virtualization Infrastructure Software, Enterprise, Network Function Virtualization Infrastructure Software, Virtualization Infrastructure Software, Infrastructure Software |
