Управление доступом для AI-агентов с помощью Alter

Разбираем Alter — решение для контроля прав доступа мультипользовательских агентов. Как обеспечить безопасность и предсказуемость при делегировании действий.

Проблема разграничения прав в агентских средах

Когда мы переходим от простых чат-ботов к полноценным AI-агентам, архитектура системы меняется коренным образом. Если обычный бот просто отвечает на вопросы, то агент получает право действовать: выполнять SQL-запросы, читать файлы или управлять инфраструктурой. С практической точки зрения, это превращает агента из информационного ресурса в полноценного участника системы с определёнными привилегиями.

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

Риски выполнения действий от имени пользователя

Самая большая проблема — это потеря гранулярности прав. В классических системах управления доступом (RBAC) мы четко знаем, кто и что сделал. Но в агентской среде часто используется единый сервисный аккаунт для всех действий.

Представьте, что вы развернули [DeepSQL: DBA агент для PostgreSQL и MySQL](/guides/razvertyvanie-deepsql-размещение на домашних серверах-dba-agent-dlya-postgresql-i-mysql-uf6iti), чтобы автоматизировать оптимизацию запросов. Если агент работает через общую учетную запись postgres, то в логах базы данных вы увидите только действия этого пользователя. Вы не сможете понять, инициировал ли тяжелый DROP TABLE реальный администратор или агент, получивший некорректную инструкцию от рядового сотрудника.

Это убивает предсказуемость. Чтобы избежать хаоса, необходимо внедрять слой проксирования, который будет сопоставлять сессию пользователя с конкретными действиями агента. Если мы посмотрим на типичный запрос к БД через агентский слой, то без контроля доступа он выглядит так:

sql
-- Опасный сценарий: агент выполняет команду в контексте суперпользователя
-- без привязки к конкретной сессии пользователя
DELETE FROM users WHERE id = 105;

Вместо этого архитектура должна строиться на принципе наименьших привилегий. Агент не должен иметь прямого доступа к базе. Он должен взаимодействовать с прокси-слоем, который проверяет: «Имеет ли право пользователь X просить агента выполнить действие Y над объектом Z?». Только так можно обеспечить аудит и безопасность.

Сложность управления сессиями в Slack и других интерфейсах

Второй критический момент — это разрыв контекста между интерфейсом взаимодействия и исполнительной средой. Большинство агентов сегодня живут внутри Slack, Telegram или веб-интерфейсов. Эти платформы не передают информацию о правах доступа пользователя в том виде, в котором она нужна бэкенду.

Когда пользователь пишет в Slack: «Удали этот лог из системы», Slack передаёт сообщение через webhook. Для вашего сервера это просто входящий JSON. В этом JSON нет информации о том, является ли этот пользователь администратором или стажёром. Если ваша логика обработки команд завязана только на тексте сообщения, вы открываете огромную дыру в безопасности.

Проблема усугубляется при попытке масштабировать систему. Если вы используете высокопроизводительные хранилища для кэширования состояний сессий, например KiviDB: быстрая Redis-совместимая БД на Rust, вам всё равно нужно гарантировать, что метаданные о правах пользователя не были подменены или потеряны при переходе от интерфейса к исполнителю.

Типичная ошибка при проектировании таких систем — попытка хранить права доступа внутри самого контекста диалога. Это не работает, потому что:

Контекст диалога может быть подделан (prompt injection).
Контекст может быть очищен или перезаписан.
Проверка прав в момент выполнения команды (runtime) должна происходить независимо от того, что «подумал» агент.

Для решения этой задачи требуется промежуточный слой, который будет работать как шлюз. Он должен перехватывать команду, сопоставлять ID пользователя из интерфейса с его реальными правами в вашей системе управления доступом и только после этого транслировать запрос агенту. Без этого механизма управление агентами превращается в игру в «русскую рулетку» с вашей инфраструктурой.

Архитектура и возможности Alter

Если мы посмотрим на типичную инфраструктуру с AI-агентами, то увидим главную проблему: агенты часто работают с избыточными правами. Вы даёте модели доступ к базе данных или API, и она, пытаясь выполнить задачу, может случайно выполнить DROP TABLE или отправить лишний запрос в сторонний сервис. Alter решает эту задачу, выступая в роли интеллектуального прокси-слоя между агентом и ресурсами.

С практической точки зрения Alter — это не просто фильтр запросов, а полноценный контроллер, который понимает контекст выполнения задачи. Он анализирует входящий поток команд, сопоставляет его с политиками доступа и решает, пропустить запрос дальше или заблокировать его, сохранив при этом логи для аудита.

Механизм контроля доступа для мультипользовательских агентов

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

Вместо того чтобы давать агенту полный доступ к базе данных, мы настраиваем правила на уровне конкретных операций и объектов. Например, если агент должен работать с KiviDB: быстрой Redis-совместимой БД на Rust, мы можем ограничить его только определёнными ключами или типами команд.

Для настройки политик используется декларативный подход. Рассмотрим пример конфигурации, где мы ограничиваем возможности агента «Пятачок» (нашего виртуального помощника по управлению задачами) только чтением из определённого набора таблиц:

yaml
# Пример политики доступа для агента
agent_id: pyatachok_01
permissions:
  - resource: postgresql://prod-db:5432/tasks
    actions:
      - SELECT
    allowed_tables:
      - user_tasks
      - task_status
    conditions:
      # Запрещаем любые операции, которые могут привести к изменению данных
      deny_on:
        - DELETE
        - DROP
        - TRUNCATE
  - resource: redis://cache-cluster:6379
    actions:
      - GET
      - MGET

Такой подход обеспечивает предсказуемость: даже если LLM (Large Language Model) «галлюцинирует» и решит очистить кэш, Alter пресечёт этот запрос ещё на подлёте к базе. Все попытки нарушения правил фиксируются в логах, что критически важно для последующего разбора инцидентов.

Интеграция с существующими рабочими процессами

Alter не требует переписывания вашего приложения или изменения логики работы самих агентов. Он встраивается в цепочку вызовов как прозрачный прокси. Если ваше решение уже использует специализированных агентов, например [DeepSQL для управления PostgreSQL и MySQL](/guides/razvertyvanie-deepsql-размещение на домашних серверах-dba-agent-dlya-postgresql-i-mysql-uf6iti), Alter может выступать в роли дополнительного эшелона защиты, проверяя команды, которые генерирует DBA-агент.

Интеграция обычно происходит на уровне сетевых настроек или переменных окружения. Вместо прямого подключения к базе данных, агент направляется на адрес, где запущен Alter.

Для развёртывания в Docker-окружении это выглядит следующим образом:

dockerfile
# Пример запуска Alter в качестве прокси-слоя
docker run -d \
  --name alter-proxy \
  -p 5433:5432 \
  -v /etc/alter/config.yaml:/etc/alter/config.yaml \
  alter-io/proxy:latest

В этом сценарии агент будет подключаться к localhost:5433, думая, что это стандартный порт базы данных, но на самом деле все его запросы будут проходить через фильтрацию.

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

Практическое применение и безопасность

Обеспечение предсказуемости действий агента

Когда мы делегируем управление инфраструктурой или базой данных AI-агенту, главная проблема — это не отсутствие способностей, а избыточность прав. В классической схеме агент получает строку подключения с правами superuser, и любая галлюцинация модели превращается в DROP TABLE. С Alter мы переходим к модели проксирования, где агент взаимодействует не с целевой системой напрямую, а с контроллером.

С практической точки зрения, предсказуемость достигается через ограничение набора разрешённых команд (allowlist). Вместо того чтобы давать агенту полный доступ к PostgreSQL, мы настраиваем Alter так, чтобы он пропускал только определённые типы запросов.

Если вы используете агентов для работы с высоконагруженными хранилищами, например, KiviDB: быстрая Redis-совместимая БД на Rust, важно ограничить область действия агента конкретными ключами или префиксами.

Пример конфигурации политики доступа в Alter, которая разрешает агенту только чтение и выполнение определённых команд, но блокирует опасные операции:

yaml
# Пример политики доступа Alter для AI-агента
access_policy:
  target: "postgresql://db-server:5432/prod_db"
  allowed_commands:
    - "SELECT"
    - "EXPLAIN"
  denied_commands:
    - "DROP"
    - "TRUNCATE"
    - "DELETE"
  # Ограничение по паттерну таблиц, чтобы агент не залез в системные схемы
  table_patterns:
    - "app_data_*"
    - "user_metrics"

Такой подход превращает агента из «неуправляемого администратора» в «ограниченного оператора». Если агент попытается выполнить команду, не входящую в список, Alter прервёт соединение и вернёт ошибку до того, как запрос дойдёт до базы данных. Это критически важно при развёртывании подобных решений, таких как [DeepSQL: DBA агент для PostgreSQL и MySQL](/guides/razvertyvanie-deepsql-размещение на домашних серверах-dba-agent-dlya-postgresql-i-mysql-uf6iti), где автоматизация действий напрямую влияет на стабильность сервисов.

Логирование и аудит выполненных операций

Любая автоматизация без прозрачного аудита — это мина замедленного действия. В случае с AI-агентами стандартных логов базы данных часто недостаточно, потому что они показывают что произошло, но не объясняют почему. Мы видим запрос DELETE FROM users, но не видим контекста: был ли это осознанный шаг агента в ответ на задачу пользователя или ошибка в логике планировщика.

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

Для эффективного аудита я рекомендую настроить экспорт логов Alter в структурированном формате JSON. Это позволит легко интегрировать их в стек Prometheus и Grafana для визуализации аномалий.

Пример того, как выглядит запись в логе Alter после выполнения запроса агентом:

json
{
  "timestamp": "2023-10-27T14:22:01.452Z",
  "agent_id": "agent-alpha-01",
  "session_id": "sess-99823",
  "action": "query_execution",
  "status": "allowed",
  "target_db": "prod_db",
  "query": "SELECT email FROM users WHERE id = 42;",
  "latency_ms": 12,
  "context": {
    "reasoning_step": "Fetching user contact info for support ticket #102"
  }
}

Обратите внимание на поле context. Если ваш агент передаёт свои «рассуждения» (reasoning) в заголовках запроса к прокси, Alter может сохранять их вместе с SQL-запросом. Это дает инженеру возможность увидеть не просто сухой текст команды, а логическую цепочку, которая к ней привела.

Если вы работаете с векторными данными, например, используя KiviDB с векторным кэшем, аудит становится ещё важнее. Вы сможете отследить, какие именно эмбеддинги запрашивал агент и не привели ли эти запросы к избыточной нагрузке на CPU при поиске по сходству.

Для настройки системного сбора этих логов через journald убедитесь, что уровень логирования в конфиге Alter установлен на info или debug:

bash
# Проверка текущего статуса логов через journalctl
journalctl -u alter-proxy -f | grep "action=query_execution"

Наличие детального лога позволяет не только расследовать инциденты, но и постоянно дообучать политики доступа, делая поведение агентов всё более предсказуемым.

Сравнение подходов к управлению доступом

Традиционные IAM-системы против специализированных решений

Когда мы говорим об управлении доступом, в голове сразу всплывают привычные IAM-решения (Identity and Access Management) вроде Keycloak или облачных AWS IAM. Они отлично справляются с классической задачей: «пользователь Иван имеет право читать файл X». Но как только в уравнение вступает AI-агент, логика ломается.

Проблема в том, что традиционные системы работают с правами на уровне субъекта (человека или сервисного аккаунта). AI-агент же — это динамический субъект. Он не просто выполняет команды, он генерирует их на основе контекста. Если вы дадите агенту доступ к базе данных через стандартный сервисный аккаунт, вы фактически даёте ему «ключи от квартиры», где лежит всё. Агент может случайно (или из-за галлюцинации) выполнить DROP TABLE, если в его системном промпте не прописаны жёсткие ограничения.

С практической точки зрения, разница заключается в уровне абстракции:

IAM-системы контролируют кто может войти в систему. Они проверяют токены, роли и политики на входе.
Специализированные решения (вроде Alter) работают как интеллектуальный прокси-слой. Они анализируют что именно агент пытается сделать в момент выполнения запроса.

Если мы посмотрим на работу с базой данных, то в классической схеме вы настраиваете права в самой БД:

sql
-- Классический подход: даём агенту права на чтение конкретной таблицы
GRANT SELECT ON users TO ai_agent_user;

Это предсказуемо, но не гибко. Если агенту понадобится проанализировать связи между таблицами для решения сложной задачи, вам придётся либо расширять его права (увеличивая поверхность атаки), либо он упрётся в ошибку Permission Denied.

Alter же выступает в роли промежуточного звена. Он позволяет реализовать принцип минимальных привилегий не на уровне статических ролей БД, а на уровне семантики запроса. Вместо того чтобы просто разрешить SELECT, вы можете настроить политику, которая разрешает агенту запрашивать данные только в рамках определённого контекста или объёма.

Когда стоит внедрять Alter в инфраструктуру

Внедрение дополнительного слоя управления — это всегда усложнение архитектуры. Я сторонник того, чтобы не добавлять звенья в цепь без явной необходимости. Однако в сценариях, где AI-агенты получают доступ к критическим данным, это становится вопросом выживания системы.

Я выделяю три основных сценария, когда использование Alter оправдано:

1. Делегирование автономных действий в БД Если вы строите систему, подобную [DeepSQL](https://example.com/guides/razvertyvanie-deepsql-%D1%80%D0%B0%D0%B7%D0%BC%D0%B5%D1%89%D0%B5%D0%BD%D0%B8%D0%B5 на домашних серверах-dba-agent-dlya-postgresql-i-mysql-uf6iti), где агент должен самостоятельно оптимизировать запросы или проводить аудит, вам нужен слой контроля. Без него риск повреждения данных слишком высок. Alter позволяет перехватывать запросы и проверять их на соответствие заданным паттернам безопасности.

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

3. Необходимость детального логирования намерений Стандартные логи базы данных (например, general_log в PostgreSQL) показывают, какой запрос пришёл, но не объясняют, почему агент его сформировал. Alter позволяет сопоставлять SQL-запрос с контекстом задачи агента. Это критически важно для отладки и аудита безопасности.

Для оценки целесообразности внедрения можно использовать простую проверку. Если ваш агент выполняет только чтение из изолированного Read-Only реплика, Alter вам не нужен. Если же агент имеет возможность выполнять UPDATE, DELETE или взаимодействовать с высоконагруженными структурами вроде масштабируемых временных шкал, то контроль через прокси становится обязательным.

Пример конфигурации политики в Alter может выглядеть так:

yaml
# Пример политики ограничения для AI-агента
policy:
  name: "restrict_ai_writes"
  target: "production_db"
  rules:
    - action: "write"
      condition: "query_complexity < 5" # Ограничение по сложности запроса
      allow: false
    - action: "read"
      condition: "rows_limit < 100"    # Защита от выкачивания всей таблицы
      allow: true

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

Заключение

Итоговая оценка безопасности

Если подводить итог, Alter решает главную проблему при работе с автономными агентами — отсутствие прозрачного контура безопасности. Когда вы делегируете ИИ право выполнять запросы к базе данных или взаимодействовать с API, вы фактически создаёте новую точку входа, которую сложно контролировать стандартными средствами RBAC.

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

Когда Alter станет необходимостью

Я рекомендую внедрять это решение в следующих сценариях:

Мультиагентные системы. Если у вас несколько агентов с разными ролями, Alter поможет изолировать их права на уровне протокола.
Работа с чувствительными данными. Если агенту нужно анализировать логи или состояние БД, прокси обеспечит маскирование данных до того, как они попадут в контекстное окно модели.
Аудит действий. Если вам нужно точно знать, какой именно агент инициировал транзакцию, которая привела к изменению состояния системы.

Для полноценного контроля за инфраструктурой важно не только ограничить права, но и настроить сбор метрик. Например, если вы используете [DeepSQL](https://example.com/guides/razvertyvanie-deepsql-%D1%80%D0%B0%D0%B7%D0%BC%D0%B5%D1%89%D0%B5%D0%BD%D0%B8%D0%B5 на домашних серверах-dba-agent-dlya-postgresql-i-mysql-uf6iti) для автоматизации администрирования, Alter станет тем самым предохранителем, который не даст агенту выполнить деструктивную команду вроде DROP TABLE в обход ваших правил.

Практические рекомендации по внедрению

Не пытайтесь сразу перевести всех агентов на проксирование через Alter. Начните с режима «Shadow Mode» (или режима логирования), чтобы увидеть реальный паттерн поведения моделей.

Сначала настройте политику, которая только фиксирует запросы, не блокируя их:

yaml
# Пример конфигурации политики в режиме наблюдения
policy:
  name: "ai-agent-audit-only"
  mode: "log" # Только запись в логи, без блокировки
  rules:
    - action: "SELECT"
      resource: "customer_data"
      allow: true
    - action: "DELETE"
      resource: "*"
      allow: false # Запрет на удаление, но в режиме log он не прервёт запрос

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

yaml
# Переход к активному управлению доступом
policy:
  name: "ai-agent-strict-control"
  mode: "enforce" # Реальная блокировка запрещённых действий
  rules:
    - action: "DELETE"
      resource: "*"
      allow: false

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

FAQ

Как Alter защищает данные пользователей?

Основной механизм защиты строится на принципе проксирования запросов. Alter выступает в роли интеллектуального посредника между AI-агентом и целевой системой (например, базой данных). Вместо того чтобы давать агенту прямой доступ к учетной записи с широкими привилегиями, вы настраиваете политики на уровне прокси.

Если агент пытается выполнить запрос, выходящий за рамки разрешённого контекста пользователя, Alter блокирует его на этапе парсинга. Это обеспечивает предсказуемость: агент не сможет случайно или намеренно прочитать данные другого пользователя, даже если в его системном промпте содержится попытка обхода ограничений (prompt injection).

Для контроля доступа к данным в реальном времени можно использовать конфигурацию политик, которая проверяет атрибуты запроса:

yaml
# Пример политики ограничения доступа к таблице users
policy:
  name: restrict_user_data
  target: postgresql://db.internal:5432
  rules:
    - action: allow
      condition: "request.user_id == resource.owner_id"
    - action: deny
      reason: "Attempt to access unauthorized user row"

Можно ли использовать Alter для внутренних инструментов?

Да, это один из наиболее подходящих сценариев. В корпоративной среде часто возникает потребность в автоматизации рутинных задач через агентов — например, для генерации отчётов или управления инфраструктурой. В таких случаях важно, чтобы агент не стал «черным ящиком» с неограниченными правами.

Если вы строите внутреннюю платформу, где агенты взаимодействуют с высоконагруженными хранилищами, Alter поможет изолировать их действия. Например, при работе с быстрыми хранилищами типа KiviDB можно настроить политики, ограничивающие количество операций в секунду (rate limiting), чтобы агент не перегрузил кэш.

Для интеграции в существующий CI/CD или внутренний инструментарий достаточно развернуть Alter как сетевой прокси и перенаправить трафик агентов на него.

Поддерживает ли решение интеграцию со Slack?

На текущий момент Alter не является готовым плагином для Slack, но он предоставляет API и возможности логирования, которые позволяют построить такую интеграцию самостоятельно.

Вы можете настроить систему так, чтобы при каждой попытке агента выполнить критическое действие (например, DROP TABLE или изменение конфигурации) Alter отправлял событие в ваш лог-менеджер, а тот, в свою очередь, транслировал уведомление в Slack-канал через webhook.

Пример структуры лога, который можно перехватить для уведомления:

json
{
  "timestamp": "2023-10-27T10:15:00Z",
  "agent_id": "agent-007",
  "action": "denied",
  "resource": "database.production.users",
  "reason": "Policy violation: unauthorized column access",
  "query": "SELECT ssn FROM users WHERE id = 123"
}

Такой подход позволяет не просто получать уведомления, а выстраивать полноценный аудит безопасности в реальном времени.

В чем основное отличие от обычных систем контроля доступа?

Традиционные системы (RBAC или ABAC) работают с правами статических пользователей или сервисных аккаунтов. Они отвечают на вопрос: «Может ли этот пользователь читать эту таблицу?».

Alter же работает с динамическим контекстом запроса, который генерирует AI. Главное отличие заключается в том, что Alter понимает семантику и намерения. Обычная БД увидит в запросе агента просто легитимный SQL-код. Alter же может сопоставить запрос с текущей сессией пользователя, который инициировал работу агента, и понять, что агент пытается выйти за рамки полномочий этого конкретного человека.

Если вам нужно развернуть полноценного DBA-агента, который будет управлять базами данных, стоит сначала изучить [руководство по развертыванию DeepSQL](https://example.com/guides/razvertyvanie-deepsql-%D1%80%D0%B0%D0%B7%D0%BC%D0%B5%D1%89%D0%B5%D0%BD%D0%B8%D0%B5 на домашних серверах-dba-agent-dlya-postgresql-i-mysql-uf6iti), чтобы понимать, как работают специализированные агенты, и использовать Alter как защитный слой поверх них. Это обеспечит необходимый уровень контроля и предсказуемости поведения системы.

Часто задаваемые вопросы

Как Alter помогает избежать выполнения команд от имени суперпользователя?

Alter внедряет слой проксирования между AI-агентом и целевой системой, что позволяет перехватывать запросы до их исполнения. Вместо использования единого сервисного аккаунта с избыточными правами, решение сопоставляет действия агента с конкретным контекстом пользователя. Это гарантирует, что агент не сможет выполнить операцию, на которую у инициировавшего запрос человека нет прав.

Можно ли использовать Alter для аудита действий агентов в базе данных?

Да, это одна из ключевых задач системы. Благодаря тому, что Alter связывает запрос модели с личностью пользователя, в логах целевой системы (например, PostgreSQL) сохраняется прозрачная история. Вы сможете точно определить, какой именно сотрудник через агента инициировал изменение структуры таблиц или удаление данных, что возвращает системе необходимую предсказуемость.

Влияет ли использование прокси-слоя на задержку (latency) при работе агента?

С практической точки зрения, любое дополнительное звено в цепочке запросов вносит небольшую задержку, но в контексте работы LLM она обычно незначительна. Время генерации токенов моделью значительно превышает время, затраченное Alter на проверку прав и проксирование команды. Важно рассматривать этот вклад как необходимую плату за безопасность и контроль над инфраструктурой.

Как Alter работает, если агент должен выполнить задачу, требующую повышенных привилегий?

В такой ситуации необходимо настроить политики доступа так, чтобы агент запрашивал временные или ограниченные полномочия, строго соответствующие задаче. Alter позволяет реализовать гранулярный подход, где права выдаются не «на всё сразу», а на конкретный тип действия в рамках текущей сессии. Это исключает ситуацию, когда агент получает доступ к критическим узлам системы без явного на то основания.

Управление доступом для AI-агентов с помощью Alter