Utgåvor som stöds för den här funktionen: Frontline Standard och Frontline Plus, Enterprise Standard och Enterprise Plus, Education Standard och Education Plus, Enterprise Essentials Plus, Cloud Identity Premium. Jämför utgåvor
I den här artikeln beskrivs vanliga användningsområden för kontextkänslig åtkomst. Den innehåller även exempelkonfigurationer som har utvecklats i grundläggande läge.
Exempel på åtkomstnivåer som har utvecklats i avancerat läge (med CEL-redigeraren) finns i Exempel på kontextkänslig åtkomst för avancerat läge.
Tillåt entreprenörsåtkomst endast via företagets nätverk
Många företag vill begränsa entreprenörens åtkomst till företagets resurser. Det kan till exempel vara företag som anlitar externa leverantörer för att svara på allmänna supportsamtal eller arbeta i hjälpcenter och callcenter. Precis som heltidsanställda måste leverantörer ha en licens som stöds för att omfattas av policyer för kontextkänslig åtkomst.
I det här exemplet får entreprenörer endast åtkomst till företagsresurser från ett specifikt IP-adressintervall för företaget.
| Namn på åtkomstnivå | contractor_access |
| En entreprenör får åtkomst om | Attribut har uppfyllts |
| Attribut för villkor 1 | IP-subnät (offentligt) 74.125.192.0/18 |
| Tilldelning av åtkomstnivå | Organisationsenheter för entreprenörer Alla appar som entreprenörer använder |
Blockera åtkomst från IP-adresser som är kända för att användas av kapare
Många företag blockerar åtkomst till kända högriskkällor för att skydda företagets resurser från att utsättas för intrång.
I det här exemplet blockeras IP-adressen 74.125.195.105. Användarna får åtkomst till företagsresurser om deras sessioner kommer från någon annan IP-adress. Du kan ange flera IP-adresser och intervall.
| Namn på åtkomstnivå | block_highrisk |
| Användare får åtkomst om | Attribut har inte uppfyllts |
| Attribut för villkor 1 | IP-subnät (offentligt) 74.125.195.105 |
| Tilldelning av åtkomstnivå | Organisationsenhet på toppnivå Alla appar |
Tillåta åtkomst från ett specifikt privat nätverk i Google Cloud
Många företag dirigerar användartrafik till Google via ett VPC-nätverk (Virtual Private Cloud). Ett VPC är ett säkert, isolerat nätverk i Google Cloud-miljön.
Tänk på att trafik som dirigeras via VPC kan använda privata IP-adresser. Detta kan orsaka problem med offentliga IP- eller regionpolicyer.
I det här exemplet kan du tillåta trafik från dessa specifika VPC:er.
| Namn på åtkomstnivå | vpc_access |
| Användare får åtkomst om de ... | Attribut har uppfyllts |
| Attribut för villkor 1 |
IP-subnät (privat) Privat IP-subnätverk: //compute.googleapis.com/projects/project- name-test/global/networks/network-name VPC-subnät: 74.125.192.0/18 |
| Tilldelning av åtkomstnivå |
Organisationsenheter för alla användare Alla appar som entreprenörer använder |
Viktigt att komma ihåg:
- Endast direkt trafik: Den här åtkomstnivån fungerar bara för trafik som når Googles servrar direkt från det godkända VPC-nätverket. Om trafiken går via ett annat nätverk eller en annan tunnel först beviljas inte åtkomst. Google känner bara igen den senaste VPC som skickar trafiken till sina servrar.
- Administratörsbehörigheter: Om du vill visa VPC:er och konfigurera denna åtkomstnivå måste administratörer ha lämplig roll för identitets- och åtkomsthantering (IAM) (till exempel compute.networks.list, compute.subnetworks.list osv.).
- Externa VPC:er: VPC:n du godkänner kan komma från en plats utanför din nuvarande Google Cloud-domän. En administratör måste ha visningsbehörighet för att lägga till det externa VPC-nätverket.
Tillåt eller avvisa åtkomst från specifika platser
Om du har anställda som regelbundet reser till fjärranslutna företags- eller partnerkontor kan du ange de geografiska platser där de kan få åtkomst till företagets resurser.
Om en grupp säljare till exempel regelbundet besöker kunder i Australien och Indien kan du begränsa gruppens åtkomst till hemmakontoret och Australien och Indien. Om de reser till andra länder för en personlig semester som en del av en affärsresa kan de inte få åtkomst till företagsresurser från de andra länderna.
I det här exemplet kan försäljningsgruppen endast få åtkomst till företagsresurser från USA (hemmakontoret), Australien och Indien.
| Namn på åtkomstnivå | sales_access |
| Säljavdelningen får tillgång om | Attribut har uppfyllts |
| Attribut för villkor 1 | Geografiskt ursprung USA, Australien, Indien |
| Tilldelning av åtkomstnivå | Grupp av säljare Alla appar som säljare använder |
Du kan även skapa en policy för att neka åtkomst från specifika länder genom att ange att användarna får åtkomst om de inte uppfyller villkoren. Du anger de länder som du vill blockera åtkomst från.
Använd kapslade åtkomstnivåer i stället för att välja flera åtkomstnivåer under tilldelningen
I vissa fall när du försöker tilldela åtkomstnivåer till en viss organisationsenhet eller grupp och en app (eller en uppsättning appar) kan ett felmeddelande visas där du ombeds minska antalet appar eller åtkomstnivåer.
Du kan förhindra det här felet genom att minska antalet åtkomstnivåer som används under tilldelningen genom att kapsla in dem i en enda åtkomstnivå. Den kapslade åtkomstnivån kopplar samman flera villkor med en ELLER-operator, där varje villkor innehåller en enskild åtkomstnivå.
I det här exemplet finns USWest, USEast och USCentral på tre separata åtkomstnivåer. Låt säga att du vill att användarna ska kunna få åtkomst till appar om de uppfyller någon av åtkomstnivåerna USWest, USEast eller USCentral.Du kan skapa en enda kapslad åtkomstnivå (kallad USRegions) med operatorn ELLER. När det är dags att tilldela åtkomstnivåerna tilldelar du åtkomstnivån USRegions till appen för organisationsenheten eller gruppen.
|
Namn på åtkomstnivå |
USRegions |
|
Användare får åtkomst om |
Attribut har uppfyllts |
|
Attribut för villkor 1 (endast en åtkomstnivå per villkor) |
Åtkomstnivå USWest |
|
Koppla samman villkor 1 och villkor 2 med |
ELLER |
|
Användare får åtkomst om |
Attribut har uppfyllts |
|
Attribut för villkor 2 |
Åtkomstnivå USEast |
|
Koppla ihop villkor 2 och villkor 3 med |
ELLER |
|
Användare får åtkomst om |
Attribut har uppfyllts |
|
Attribut för villkor 3 |
Åtkomstnivå USCentral |
Kräv företagsägd på datorn men inte på mobil enhet
Ett företag kan kräva en företagsägd dator, men inte en företagsägd mobil enhet.
Skapa först en åtkomstnivå för datorer:
|
Namn på åtkomstnivå |
aldesktop_access |
|
Användare får åtkomst om |
Attribut har uppfyllts |
|
Attribut för villkor 1 |
Enhetspolicy
Enhetskryptering = Stöds inte Enhetens operativsystem macOS = 0.0.0 Windows =0.0.0 Linux OS = 0.0.0 Chrome OS = 0.0.0 |
Skapa sedan en åtkomstnivå för mobila enheter:
|
Namn på åtkomstnivå |
almobile_access |
|
Användare får åtkomst om |
Attribut har uppfyllts |
|
Attribut för villkor 1 |
Enhetens operativsystem iOS = 0.0.0 Android = 0.0.0 |
Kräv grundläggande enhetssäkerhet
De flesta företag kräver nu att anställda får åtkomst till företagsresurser via enheter som är krypterade och uppfyller minimiversioner för operativsystem. Vissa kräver också att anställda använder företagsägda enheter.
Du kan konfigurera dessa policyer för alla organisationsenheter eller bara för dem som arbetar med känslig data, till exempel företagsledningen, ekonomiavdelningen eller personalavdelningen.
Det finns flera sätt att konfigurera en policy som omfattar enhetskryptering, lägsta operativsystemversion och företagsägda enheter. De har alla för- och nackdelar.
En åtkomstnivå som innehåller alla säkerhetskrav
I det här exemplet ingår enhetskryptering, minimiversion av operativsystem och attribut för företagsägda enheter i en åtkomstnivå. Användarna måste uppfylla alla villkor för att få åtkomst.
Om en användarenhet till exempel är krypterad och företagsägd men inte kör en kompatibel version av operativsystemet nekas användaren åtkomst.
Fördel: Enkel att konfigurera. När du tilldelar en app denna åtkomstnivå måste en användare uppfylla alla krav.
Nackdel: Om du vill tilldela säkerhetskraven till olika organisationsenheter separat måste du skapa en separat åtkomstnivå för varje säkerhetskrav.
| Namn på åtkomstnivå | device_security |
| Användare får åtkomst om | Attribut har uppfyllts |
| Attribut för villkor 1 (Du kan lägga till alla attribut i ett villkor eller skapa tre villkor och koppla dem till OCH.) |
Enhetspolicy Enhetens operativsystem |
Tre separata åtkomstnivåer
I det här exemplet finns attributen för enhetskryptering, minimiversion av operativsystem och företagsägd enhet på tre olika åtkomstnivåer. Användarna behöver bara uppfylla villkoren på en åtkomstnivå för att få åtkomst. Det är ett logiskt ELLER för åtkomstnivåer.
En användare som har en krypterad enhet och kör en äldre version av operativsystemet på en personlig enhet får till exempel åtkomst.
Fördel: Ett detaljerat sätt att definiera åtkomstnivåer. Du kan tilldela olika organisationsenheter åtkomstnivåer separat.
Nackdel: Användarna måste uppfylla villkoren på endast en åtkomstnivå.
| Namn på åtkomstnivå | device_encryption |
| Användare får åtkomst om | Attribut har uppfyllts |
| Attribut för villkor 1 |
Enhetspolicy |
| Namn på åtkomstnivå | corp_device |
| Användare får åtkomst om | Attribut har uppfyllts |
| Attribut för villkor 1 |
Enhetspolicy |
| Namn på åtkomstnivå | min_os |
| Användare får åtkomst om | Attribut har uppfyllts |
| Attribut för villkor 1 |
Enhetspolicy |
En åtkomstnivå med kapslade åtkomstnivåer
I det här exemplet finns säkerhetskraven för enhetskryptering, minimiversion av operativsystem och företagsägd enhet på tre olika åtkomstnivåer. Dessa tre åtkomstnivåer är kapslade inuti en fjärde åtkomstnivå.
När du tilldelar apparna den fjärde åtkomstnivån måste användarna uppfylla villkoren på var och en av de tre kapslade åtkomstnivåerna för att få åtkomst. Det är ett logiskt OCH för åtkomstnivåer.
En användare som har en krypterad enhet och kör en äldre version av operativsystemet på en personlig enhet nekas till exempel åtkomst.
Fördel: Du behåller flexibiliteten att dela upp säkerhetskraven på åtkomstnivåerna 1, 2 och 3. Med hjälp av åtkomstnivå 4 kan du även tillämpa en policy med alla säkerhetskrav.
Nackdel: Granskningsloggen registrerar endast nekad åtkomst till åtkomstnivå 4 (inte till åtkomstnivåerna 1, 2 och 3) eftersom åtkomstnivåerna 1, 2 och 3 inte tilldelas appar direkt.
Skapa tre åtkomstnivåer enligt beskrivningen i Tre separata åtkomstnivåer ovan: device_encryption, corp_device och min_os. Skapa sedan en fjärde åtkomstnivå som heter device_security med tre villkor. Varje villkor har en åtkomstnivå som attribut. (Du kan bara lägga till en åtkomstnivåattribut per villkor.)
| Namn på åtkomstnivå | device_security |
| Användare får åtkomst om | Attribut har uppfyllts |
| Ett villkorsattribut (endast en åtkomstnivå per villkor) |
Åtkomstnivå device_encryption |
| Koppla samman villkor 1 och villkor 2 med | OCH |
| Användare får åtkomst om | Attribut har uppfyllts |
| Attribut för villkor 1 | Åtkomstnivå corp_device |
| Koppla ihop villkor 2 och villkor 3 med | OCH |
| Användare får åtkomst om | Attribut har uppfyllts |
| Attribut för villkor 1 | Åtkomstnivå min_os |