AarView Documentation
Version described: 1.78.0 The managed SOC: AarSOC documentation →
Documentation contents

AarView · Operate

Security model

How AarView protects accounts, sessions and data: least-privilege directory account, two-factor authentication, lockout, database isolation, TLS.

On this page

The identity provider

AarView installs with its identity provider (Authentik), configured by the installer.

  • The portal never holds the identity provider’s admin token. It uses a limited directory account, which can:
    • read users and groups;
    • create users, and change only the users it created;
    • manage membership of the AarView role groups.
  • That account cannot create or edit a group, touch an administrator, or read the identity provider’s configuration.
  • The installer checks these rights at the end of the installation and stops if they do not match. A check script proves it on a running install (28 checks).
  • An account’s client is an attribute of that account, not a group.

Accounts

  • Two-factor authentication is mandatory for everyone (TOTP app), from the first sign-in.
  • Lockout: 5 failed sign-ins lock an account for AARVIEW_LOCKOUT_SECONDS (900 seconds by default).
  • Passwords of at least 12 characters, refused when easy to guess.
  • Set-password links: a link only changes the account it was issued for.
  • Recent sign-in required for sensitive actions (accounts, licence, machine access, sources, clients, offers, audit export): less than 10 minutes.
  • Sign-in checks PKCE and a state parameter against request forgery.

Sessions

  • Closed after 30 minutes of inactivity. Only real use counts (navigation, keyboard, mouse); a banner warns five minutes before.
  • Maximum duration of 8 hours from sign-in, whatever the activity.
  • Signing out revokes the session’s tokens at the identity provider, whether the end comes from the user, inactivity or the maximum duration.
  • Signed-in pages are not cached by the browser, and tokens are not exposed to the page’s scripts.

Data

  • The database’s application role is bound by row-level security: a session sees only its client’s rows, and a session without a client sees none.
  • The client of a received alert is never read from its content: it comes from the credential or the source that sends it.
  • Connected source and webhook secrets are stored encrypted.
  • Machine access secrets are kept only as a hash.
  • Actions are written to an audit log.

Network

  • One published port: 443.
  • Only AARVIEW_DOMAIN is served (strict SNI), over TLS 1.2 or later with forward-secret cipher suites, HSTS and the usual security headers.
  • TLS to your engines is verified.
  • Outbound flows to public sources carry no data of yours, and can be switched off: see Requirements.

Licence

The licence is checked on every user route. Alert intake, however, is never blocked by the licence. See Licence.