Жизнь с персональными токенами доступа: владение, истечение и ротация

Каждый токен принадлежит человеку

Персональный токен доступа выдаётся конкретному человеку, на его имя, и несёт ровно те права в Tableau, которые у этого человека уже есть. Именно поэтому на нём стоит строить границу управления: всё, что сделано с его помощью, владелец мог бы сделать и так, и каждая строка аудита ниже по потоку честно несёт его имя.

Это также делает токен административным объектом, а не техническим. У него есть владелец, у владельца команда, у команды график дежурств. Почти всё неудобное на этой странице следует из этого одного факта.

Первый артефакт, который стоит завести, это реестр: одна строка на токен с названием задачи, которую он обслуживает, ответственным человеком, местом хранения и датой истечения. Четыре строки пишутся за десять минут и отвечают на вопрос, который иначе занимает утро: если я это отзову, что остановится.

Одна активная сессия на токен и как это учитывать

Tableau Cloud допускает одну активную сессию на токен. Каждый новый вход с этим токеном завершает предыдущую сессию, что удобно, пока им пользуется один человек, и неудобно в тот момент, когда пользуются двое.

Пакет построен вокруг этого поведения, а не против него. Шлюз входит один раз, создаёт одну сессию Tableau и передаёт эту единственную сессию каждому инструменту. Инструменты делят её, вместо того чтобы каждый входил заново с тем же токеном и обнулял предыдущий вход.

То же правило определяет поведение долгой задачи. Прежде чем запуск миграции из источника Cloud будет утверждён, предварительная проверка говорит об этом прямым текстом: используйте токен, выделенный для этого запуска, под именем, которое больше ничем не используется, и убедитесь, что его не делит ни расписание, ни вкладка браузера, ни второе устройство. Запуск повторяет неудачные аутентификации разнесёнными по времени раундами: одна коллизия переживаема, но клиент, который продолжает входить с тем же токеном, всё равно его задушит. Источник Server терпит параллельные сессии на одном токене, и поэтому привычка, безобидная годами, может застать команду врасплох при первом запуске с Cloud.

Запланированная задача и человек, которые как будто мешают друг другу, это обычно именно оно, и выглядит оно как периодическая нестабильность продукта, а не как проблема с учётными данными, которой является. Проверьте, какой токен держит каждая сторона, прежде чем расследовать что-либо ещё.

Что истечение делает с автоматизацией

У токена есть срок истечения, и автоматизация, построенная на нём, наследует эту дату, больше никогда её не упоминая. Сбой приходит при следующем запланированном запуске, а не в момент истечения. Разрыв между смертью токена и тем, когда кто-то об этом услышит, равен одному полному циклу. Для ежемесячной задачи это месяц.

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

Там, где запланированный запуск может откатиться с персонального токена на сервисные учётные данные, ответ дизайна мал, но решающ: какие учётные данные на самом деле прошли аутентификацию, записывается в запуске и показывается в строке. Без этой записи тихий откат остаётся непочиненным, и проблема всплывает лишь тогда, когда отказывает и сам откат.

Неудавшийся запуск всё равно взводит следующий: расписание, переставшее продвигаться, остаётся постоянно просроченным, и исполнитель продолжает за него браться.

Когда владелец токена уходит

Учётная запись уходит, и токен уходит вместе с ней. Это правильное поведение, и это же момент, когда несколько необслуживаемых задач останавливаются разом, и ни одна из них не значится в чек-листе увольнения.

Человек на сайте Tableau может владеть шестью видами вещей: рабочими книгами, опубликованными источниками данных, потоками, проектами, подписками и задачами обновления. Его токены седьмой вид, и в отличие от остальных шести токен не появляется ни в одном дереве проектов. Займитесь им в тот же час, что и контентом, которым он владеет, иначе расписание найдёт его за вас.

• Переназначению нужен получатель, который может владеть контентом: роль уровня Creator, Explorer с правом публикации или роль администратора. Получатель вне этого набора это несоответствие роли, и его стоит поймать в плане, до того как запуск пройдёт половину пути.
• Каждый элемент получает нового владельца с именем. Получатель переназначения обязателен всегда: контент перемещается, но никогда не удаляется по пути.
• Контент со встроенными учётными данными помечается отдельно, потому что передача источника данных новому владельцу не аутентифицирует его подключение заново.
• Лицензию стоит записать в момент освобождения. Роль на сайте соответствует уровню, и запуск записывает, что было возвращено, ту цифру, которую финансовый разговор спросит три месяца спустя.

Офбординг и гигиена токенов это одна дисциплина, увиденная с двух концов. Реестр, называющий ответственного за каждый токен, превращает разговор об увольнении в поиск по списку, а не в расследование.

Ротация токена, пока работа продолжается

Ротация идёт не так, когда её проводят как замену. Проведённая как наложение, она проходит без событий.

1. Сначала выпустите новый токен, названный по задаче, которую он будет обслуживать, со свежим сроком истечения, который вы запишете в ту же минуту.
2. Установите его туда, где живёт старый. Установка заменяет предыдущие учётные данные, а не добавляется к ним.
3. Запустите задачу один раз вручную, затем прочитайте строку. В ней должно быть сказано, что аутентифицировался персональный токен, а не сервисные учётные данные.
4. Отзовите старый токен только после того, как эта строка станет зелёной.
5. Занесите новый срок истечения в общий календарь на две недели раньше и считайте запись самой работой, а не напоминанием.

Шаг установки безопасно выполнять во время работы. Закреплённые учётные данные записываются во временный файл и затем перемещаются на место, поэтому запуск, начавшийся посреди ротации, читает либо старые учётные данные, либо новые и никогда половину файла.

Третий шаг как раз тот, который пропускают, и единственный, который что-то доказывает. Если запуск удался на сервисных учётных данных, персональный токен уже сломан, ротация ничего не проверила, и вы только что отозвали своё доказательство.

Там, где токен закреплён администратором для размещённого развёртывания, элемент выхода намеренно скрыт, потому что следующая загрузка страницы всё равно переподключит его. Эти учётные данные меняют в консоли администратора, там, где их и станет искать любой, кому они нужны.

Где живут учётные данные, когда никто не вошёл

Секреты в этом пакете живут только в рамках сессии, и это чисто работает, пока задача не должна запуститься в половине третьего ночи, когда никого нет. Исключение явное, узкое, и его стоит понять, прежде чем на него полагаться.

• Планировщик хранит расписание, периодичность и срок хранения. Собственных учётных данных он намеренно не хранит.
• Секрет разрешается на стороне сервера и передаётся короткоживущей точке доступа, которая входит, забирает то, за чем пришла, и выходит.
• Закреплённый токен зашифрован при хранении, никогда не журналируется и никогда не возвращается в браузер: вызов статуса возвращает только имя токена. Один клик его удаляет.
• Под машинным ключом каждая пользовательская область запечатывает свои учётные данные собственным производным ключом. Токен одного человека нельзя прочитать с помощью токена другого.

Одна строка в этом списке делает больше, чем кажется. Сайт, на который указывает расписание, проставляется на стороне сервера из живой сессии и никогда не читается из запроса, потому что вызывающий, способный его задать, мог бы направить запланированный запуск на другой сайт, держа чужие учётные данные.

Рутина, которая переживёт напряжённый квартал

1. Пересматривайте реестр, когда кто-то приходит или уходит, а не по квартальному циклу, который никто не соблюдает.
2. Давайте каждой необслуживаемой задаче собственный токен. Делить один с человеком это то, что порождает выход из сессии, который никто не может объяснить.
3. Раз в месяц читайте записанные учётные данные на запланированных запусках. Две минуты, и это единственное место, где всплывает тихий откат.
4. Ротируйте с наложением: выпустить, установить, доказать одним запуском, затем отозвать.
5. Сохраняйте строку отозванного токена и отмечайте дату рядом. История это то, что делает следующее расследование коротким.

Всё это обыденно. Это та часть управления учётными данными, к которой ни один интерфейс никогда никого не подталкивает. Запишите один раз и храните.