> For the complete documentation index, see [llms.txt](https://docs.cerrix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/admin-settings/ip-whitelisting.md).

# IP-hvitelisting

Du kan begrense tilgangen til CERRIX-miljøet ditt til et definert sett med IP-adresser, slik at applikasjonen bare kan nås fra ditt eget nettverk (eller andre betrodde steder). CERRIX støtter to former for IP-hvitlisting: **myk** og **hard**.

## Myk IP-hvitlisting

Med myk IP-hvitlisting administrerer du listen over tillatte IP-adresser **selv, direkte i applikasjonen**. Dette gir deg full Kontroll: du kan legge til eller fjerne IP-adresser når nettverksoppsettet ditt endres, uten å involvere CERRIX.

Siden hvitelisten vedlikeholdes hos deg, lagrer ikke CERRIX en kopi av den myke hvitelisten din. Hvis du feilsøker et tilkoblingsproblem (for eksempel etter å ha byttet til et nytt nettverk eller en ny tjenesteleverandør), bør du starte med å gjennomgå IP-adressene som er konfigurert i ditt eget miljø.

<figure><img src="https://3330106213-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-3a6866bdf6f3ead094e4dee424cebebd9a8ced5d%2Fip-whitelisting-user-profile.png?alt=media" alt="IP Whitelisting on a user profile: the whitelisted addresses with their expiration date"><figcaption></figcaption></figure>

## Hard IP-hvitlisting

Med hard IP-hvitlisting konfigureres begrensningen av **CERRIX DevOps** i CERRIX-infrastrukturen, slik at bare trafikk fra IP-adressene dine på hvitelisten når miljøet ditt.

For å sette opp hard IP-hvitlisting, kontakt CERRIX support via servicedesken og oppgi:

* den **listen over IP-adresser** som skal være tillatt, og
* den **dato og klokkeslett** for når du ønsker at endringen skal implementeres.

### Testing i akseptmiljøet

Hard IP-hvitlisting kan først settes opp i **akseptmiljøet**. Dette lar deg bekrefte at alle tiltenkte brukere og systemer fortsatt kan nå CERRIX før samme konfigurasjon brukes i produksjon.

## IP-begrensninger for API-nøkler

I tillegg til hvitlisting på miljønivå kan hver **API-nøkkel** begrenses til sin egen liste over **Tillatte IP-adresser**IP-adresser, konfigurert per nøkkel på [API-nøkkeladministrasjonssiden](/cerrix-documentation-no/cerrix-funksjoner/admin-settings/api-key-management-and-setup.md). Dette lar deg kombinere begge lagene: hvitlisting på miljønivå styrer hvem som kan nå CERRIX-miljøet ditt, mens IP-begrensninger per nøkkel sikrer at hver integrasjon bare kan bruke API-nøkkelen sin fra systemene du forventer.

## Whitelist-oppføringer administrert av CERRIX

Noen oppføringer i hvitelisten din opprettes og administreres av **CERRIX** for å holde plattformen fungerende ende til ende. Eksempler inkluderer:

* **Dokumentredigering (WOPI)-oppføringer** — dokumentredigeringstjenesten kaller tilbake til miljøet ditt, så adressene dens må være på hvitelisten. Det finnes separate oppføringer for akseptmiljøet og produksjonsmiljøet ditt, fordi programvareversjonene kan være forskjellige på de to.
* **CERRIX-supporttilgang** — oppføringer som lar CERRIX nå miljøet ditt for å gi support.

Disse oppføringene må bli stående for at plattformen skal fungere. Når du går gjennom hvitelisten din, la dem være som de er — og hvis du er usikker på hva en bestemt oppføring er til for, kontakt CERRIX support via servicedesken i stedet for å fjerne den. Support kan også bekrefte de gjeldende CERRIX-adressene for deg, ettersom disse kan endres over tid.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/admin-settings/ip-whitelisting.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
