Разделение повседневных и привилегированных операций при сопровождении Data Lake

1.

Персональные ЭУЗ
для сопровождения Data Lake
Зачем разделять повседневную работу и операции,
которые могут повредить данные PROD
Предложение для обсуждения • Октябрь 2026

2.

П Р Е Д ЛОЖЕ НИ Е П О ЭУ З
Почему вообще возник вопрос
РЕАЛЬНЫЙ ПРИМЕР
В ЧЁМ СИСТЕМНЫЙ РИСК
При работе через Kyuubi после обновления
страницы восстановилась ранее
использованная команда TRUNCATE.
Одна сессия
для двух разных
классов действий
Инженер собирался выполнить другой запрос, но в рабочей
сессии оставалась возможность удалить данные.
Диагностика и потенциально
разрушительные операции
доступны в одном контексте.
Речь не о поиске виноватого, а о дополнительной защите от повторения сценария.
Сопровождение Data Lake • Рабочее предложение
02

3.

П Р Е Д ЛОЖЕ НИ Е П О ЭУ З
В чём проблема текущего подхода
ОДИН РАБОЧИЙ КОНТЕКСТ
Обычная УЗ
инженера
Чтение, диагностика, проверка данных
Изменение и удаление данных, DDL
Проблема не в конкретной команде TRUNCATE. Проблема — в постоянных
избыточных правах в обычной сессии.
Сопровождение Data Lake • Рабочее предложение
03

4.

П Р Е Д ЛОЖЕ НИ Е П О ЭУ З
Что предлагаю сделать
Разделить повседневные и привилегированные действия — не вводя согласование каждого запроса.
ОБЫЧНАЯ ПЕРСОНАЛЬНАЯ УЗ
ПЕРСОНАЛЬНАЯ ЭУЗ
Для ежедневной работы
Для контролируемых изменений
SELECT и проверка данных
Изменение содержимого таблиц
Диагностика, просмотр метаданных
ALTER / DROP и другие DDL
Без лишних прав на изменение PROD
Отдельная сессия и аудит
Точный набор прав определим по Ranger и реальным задачам сопровождения.
Сопровождение Data Lake • Рабочее предложение
04

5.

П Р Е Д ЛОЖЕ НИ Е П О ЭУ З
Что мы от этого получим
Меньше случайных
ошибок
В обычной сессии опасный запрос
должен остановиться на проверке
прав — до изменения данных.
Понятное разделение
Проще контролировать
Рутинная работа не требует
постоянных расширенных прав.
Для изменения данных —
отдельный вход.
Понятнее, кто и когда использовал
повышенные полномочия, и зачем
они вообще нужны.
Важно: ЭУЗ не исключает ошибки под привилегированной учёткой и не заменяет резервное
копирование.
Сопровождение Data Lake • Рабочее предложение
05

6.

П Р Е Д ЛОЖЕ НИ Е П О ЭУ З
Что могут возразить — и мой ответ
«Под ЭУЗ можно точно так же
ошибиться»
Да. Но обычная диагностика перестанет быть
привилегированной. Это ещё один барьер, а не гарантия.
«Это замедлит работу и аварийные
изменения»
Чтение и диагностика остаются без переключений. Для аварий
нужен быстрый доступ к своей ЭУЗ.
«У нас уже есть ЗНИ и инструкции»
Они регулируют процесс, но сами по себе не блокируют
команду, выполненную не в том контексте.
«У нас же есть бэкапы»
Бэкап помогает восстановиться после ошибки. Разделение
прав должно снижать вероятность самой ошибки.
Сопровождение Data Lake • Рабочее предложение
06

7.

П Р Е Д ЛОЖЕ НИ Е П О ЭУ З
Технический нюанс: у нас Ranger и Kyuubi
RANGER
KYUUBI / SPARK
INSERT и TRUNCATE могут
проверять одно право — UPDATE.
Нужно проверить, кто реально
исполняет SQL и где
проверяются права.
По стандартной матрице Ranger для Hive нельзя
обещать «оставим INSERT, отдельно запретим
TRUNCATE» без проверки реализации.
Также проверить прямой доступ через HDFS и
другие клиенты — иначе ограничение можно
обойти.
Вывод: сначала проверяем работающие механизмы авторизации, потом утверждаем матрицу прав.
Основа для проверки: Apache Ranger — Hive Commands to Ranger Permission Mapping
Сопровождение Data Lake • Рабочее предложение
07

8.

П Р Е Д ЛОЖЕ НИ Е П О ЭУ З
Не предлагаю внедрять вслепую
Сначала небольшой пилот на тестовых объектах и ограниченной группе инженеров.
1
Разобрать реальные права
3
Какие действия нужны под обычной УЗ; что
уходит в ЭУЗ.
2
Проверить запреты
SELECT, INSERT, TRUNCATE, ALTER, DROP
под разными УЗ.
Сопровождение Data Lake • Рабочее предложение
Проверить пути обхода
Hive, Kyuubi / Spark, HDFS и другие
доступные интерфейсы.
4
Оценить влияние на работу
Скорость переключения, аудит, доступ при
инциденте.
08

9.

П Р Е Д ЛОЖЕ НИ Е П О ЭУ З
Что предлагаю согласовать сейчас
01
Проверку технической
реализуемости
Совместно с ответственными за Ranger, Hive/Kyuubi и
доступы.
02
Небольшой пилот
Без изменения промышленных данных и без массовой
выдачи ЭУЗ.
03
Решение по результатам
Матрица прав, подтверждённые запреты, оставшиеся
риски и трудозатраты.
Цель — не новые учётки сами по себе, а меньше полномочий в обычной рабочей сессии.
Сопровождение Data Lake • Рабочее предложение
09

10.

Д Л Я Т Е Х НИ Ч ЕСК ОГО О Б СУ ЖД Е НИ Я
Дополнение: что важно не перепутать
Версия Hive
В нашей среде Hive 4.0.0. Но сама версия не говорит, какие права проверяются в
Kyuubi.
Ranger
Стандартная матрица команд Hive относит INSERT и TRUNCATE к UPDATE; ALTER и
DROP — отдельные права.
Kyuubi / Spark
Нужно подтвердить эффективную УЗ, интеграцию с Ranger и работу ограничений на
разных путях выполнения.
Проверка результата
Не только наличие учёток, но и отказ в опасных операциях под обычной УЗ —
включая попытки в обход SQL-клиента.
Источники: Apache Ranger — Hive Commands to Ranger Permission Mapping; Apache Kyuubi — Spark AuthZ Plugin.
Сопровождение Data Lake • Рабочее предложение
10