Подходит ли LRO для compliance и аудита?

LRO построен вокруг того, о чём спрашивает аудитор: кто к чему имеет доступ, кто что сделал и может ли кто-то в середине прочитать данные. Вот как закрыт каждый пункт.

Append-only аудит-лог

Действия, совершённые в панели, пишутся в аудит-лог, который работает в режиме append-only — записи добавляются, но не редактируются и не удаляются на месте. Что фиксируется:

• Туннели и доступ: туннели созданы, изменены, удалены, поставлены на паузу и возобновлены; права выданы, отозваны и изменены.
• Аккаунты и агенты: учётные записи созданы, изменены и удалены; смены пароля; создание, изменение, удаление и смена режима/возможностей агента; эндпоинты созданы, изменены и удалены.
• Организации: приглашения выданы, приняты и отозваны, участники вошли или вышли.
• Биллинг и администрирование: подписки начаты, отменены, продлены и сменили план; настройки автопополнения и пополнения; изменения тарифов и пакетов (планы, пакеты трафика и coin); корректировки баланса и кредитного лимита администратором.
• Инфраструктура: ядра зарегистрированы, удалены и переведены в drain.

Каждая запись фиксирует пользователя и его IP-адрес — или саму систему для автоматических событий вроде продления подписки — и пишется в той же транзакции базы данных, что и изменение, поэтому запись и действие фиксируются вместе, а не как best-effort постфактум. Лог фиксирует, кто что сделал в панели; это не запись сессий и не кейлоггер, а финансовый журнал сумм и балансов живёт в отдельной истории биллинга.

Операторы не могут читать ваш трафик

Трафик туннеля сквозно зашифрован между агентами. Сервер ретранслирует непрозрачный шифртекст и не держит ключа для расшифровки, поэтому «провайдер может читать наши сессии» в этой модели просто не риск.

Доступ по принципу наименьших привилегий

Доступ гранулярен: организации группируют машины, а права назначаются на пользователя и на эндпоинт, поэтому человек видит и достаёт только то, что ему выдали. Это прямо ложится на ожидания least-privilege и разделения обязанностей.