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

Когда платформа управления ссылками проходит проверку корпоративной закупки, разговор перестает быть о функциях и становится о контролях. Кто может видеть какие ссылки? Где хранятся данные кликов? Что происходит, когда сотрудник уходит из компании? Что на самом деле охватывает SLA?

Эти вопросы не бессмысленны. Сокращатель ссылок — это инфраструктура, и как любая инфраструктура, она работает с пользовательскими данными, находится перед вашим брендом и должна корректно работать при отказе. Этот пост описывает, как Linkly отвечает на каждый вопрос, который возникает при реальной проверке корпоративной безопасности — честно, без частей, которые мы не можем подтвердить.

SSO и аутентификация

Единая система входа (SSO) — первое, о чем спрашивают большинство IT-команд, и это справедливо. Управление отдельными учетными данными для каждого SaaS-инструмента в стеке компании — это риск безопасности, который означает больше паролей для фишинга, больше учетных записей для отключения и меньше видимости того, кто имеет доступ к чему.

Enterprise-план Linkly поддерживает SSO через SAML 2.0, что означает, что он подключается к любому поставщику идентификации, который ваша компания уже использует — Okta, Azure Active Directory, Google Workspace, OneLogin или любому другому совместимому с SAML поставщику. После настройки SSO члены вашей команды входят через существующего поставщика идентификации. Linkly никогда не хранит их пароль.

Практическое преимущество помимо безопасности: offboarding происходит автоматически. Когда сотрудник уходит из компании и его учетная запись отключается в вашем поставщике идентификации, доступ к Linkly одновременно отзывается. Нет отдельного шага администратора, нет риска того, что учетные данные бывшего сотрудника все еще работают через полгода.

SAML SSO доступен в Enterprise-плане. Если вы оцениваете Linkly для развертывания значительного масштаба, настройка SSO — это стандартная часть процесса onboarding, и команда Linkly поможет вам на этом пути.

Журналы аудита

Журналы аудита существуют, чтобы ответить на конкретный вопрос: кто что сделал и когда? Для команд безопасности это не опционально — это то, что вы показываете аудитору, и это то, как вы восстанавливаете события, когда что-то идет не так.

Enterprise-журнал аудита Linkly фиксирует действия на уровне учетной записи и рабочего пространства. Когда ссылка создается, редактируется или удаляется, журнал это записывает. Когда пользователь добавляется или удаляется из рабочего пространства, журнал это записывает. Когда изменяются разрешения, журнал это записывает. Журнал доступен администраторам учетной записи и может быть экспортирован для внедрения в вашу SIEM или систему управления логами.

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

Журнал аудита — это не маркетинговая функция. Это контроль, и он существует, потому что корпоративные развертывания в нем нуждаются.

Пользовательские домены в масштабе

Для большинства компаний короткий домен также является активом бренда. Ссылка, которая отправляется в письме, текстовом сообщении или печатном QR-коде, несет ваш домен — не наш, не универсальный домен сокращателя.

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

Для корпоративных учетных записей с несколькими брендами, регионами или бизнес-подразделениями, модель рабочего пространства Linkly хорошо отображается на вашу стратегию домена. Каждому рабочему пространству можно назначить свои домены. Холдинг с пятью брендами может управлять ссылками каждого бренда на домене этого бренда, с полным разделением аналитики, управления доступом и управления ссылками — при этом выставление счетов и отчетность руководства объединяются на одной учетной записи.

Provisioning доменов в масштабе — добавление десятков доменов для крупного развертывания или портфолио клиентов — может быть обработано через API, что означает, что это вписывается в рабочий процесс infrastructure-as-code, а не требует ручного шага администратора для каждого домена. Это одна из областей, где глубина API Linkly имеет значение: управление доменами не заблокировано в workflow только для UI.

Размещение данных

Где живут ваши данные — имеет значение. Это имеет значение для соответствия GDPR, если ваши пользователи в ЕУ, это имеет значение для внутренних политик управления данными, и все чаще имеет значение для переговоров по контрактам с корпоративными клиентами, которые имеют свои собственные требования суверенитета данных.

Инфраструктура Linkly по умолчанию работает на Google Cloud с первичной обработкой в Соединенных Штатах. Для организаций с требованиями к размещению данных в ЕУ, Linkly может обсудить варианты размещения на уровне Enterprise. Это не самообслуживаемая конфигурация — это разговор о ваших специфических требованиях и о том, может ли инфраструктура Linkly их принять. Мы предпочитаем провести этот разговор честно, чем обещать что-то, что мы не можем доставить.

Данные о событиях кликов могут быть потоковой передачей в вашу инфраструктуру через webhooks (доступны в плане Business и выше) или через встроенную синхронизацию BigQuery (Enterprise). Если ваша политика управления данными требует, чтобы лично идентифицируемая информация никогда не покидала конкретную среду, полезные нагрузки webhook могут быть настроены на исключение полей PII перед доставкой. Это дает вашей команде данных поток событий кликов в реальном времени без того, чтобы Linkly хранил данные, которые вы предпочли бы сохранить в своей собственной инфраструктуре.

Для команд, которым нужно, чтобы данные кликов жили полностью в их собственном хранилище, синхронизация BigQuery — самый прямой путь. События попадают в ваш набор данных BigQuery в реальном времени, готовые к запросам рядом с вашими данными продукта и CRM, без необходимости в dashboard Linkly как части рабочего процесса отчетности.

SLA и надежность

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

Инфраструктура перенаправления Linkly обслужила более одного миллиарда кликов. Путь перенаправления архитектурно отделен от management UI и API, поэтому производительность dashboard не влияет на скорость перенаправления. Latency перенаправления составляет менее одной миллисекунды на edge. Публичная страница статуса на status.linklyhq.com отражает текущее состояние всех компонентов в реальном времени.

Enterprise-план включает контрактный SLA с гарантиями uptime на пути перенаправления и определенные service credits, если эти гарантии не соблюдаются. Это форма, которую нужно принять обязательство надежности для корпоративной закупки — публичная страница статуса полезна для видимости, но контрактный SLA с credits — это то, что попадает в соглашение с поставщиком.

Если вы оцениваете Linkly для use case, где отказы ссылок — это P1-инциденты — transactional emails, magic links, reset паролей, referral flows в продукте — разговор об SLA — это одна из первых вещей. Команда Linkly может пройти через специфику и то, как выглядит структура credits для вашего ожидаемого объема.

Гибкость контракта

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

Enterprise-план Linkly включает:

Пользовательское соглашение об обработке данных (DPA), которое документирует, как Linkly обрабатывает личные данные от вашего имени, кто are the sub-processors, и каковы обязательства с обеих сторон. Это то, что вам нужно, чтобы ваша юридическая команда подписала соответствие GDPR для обработки данных кликов.

Главное соглашение об оказании услуг (MSA), которое может быть согласовано, чтобы отразить ваши конкретные требования — ограничения ответственности, возмещение убытков, гарантийные условия и любые другие положения, которые требует ваша юридическая команда. Мы не take-it-or-leave-it SaaS на стороне контракта для корпоративных клиентов.

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

Гибкие структуры продления, включая многолетние соглашения, где экономика имеет смысл. Обязательства по объему, предоплаченные пакеты кликов и пользовательское ценообразование для крупномасштабных развертываний — это все то, что команда Linkly регулярно согласовывает.

Как работает корпоративный Onboarding

Корпоративные развертывания в Linkly следуют структурированному процессу, а не самообслуживанию. Типичная форма:

Discovery call для понимания вашей стратегии домена, структуры команды, требований данных и любых специфических потребностей соответствия. Большинство важных архитектурных вопросов — setup рабочего пространства, назначение домена, место назначения данных — получают ответ здесь.

Trial period в Enterprise-плане, чтобы ваша команда могла проверить конфигурацию SSO, доступ к журналу аудита и интеграцию API перед любым коммерческим обязательством. Мы хотим, чтобы evaluation происходила в реальном развертывании, а не в demo account.

Negotiation контракта, охватывающая DPA, MSA, условия выставления счетов и специфику SLA. Это обычно проходит параллельно с технической оценкой.

Onboarding с выделенным контактом, который остается доступным во время первого цикла кампании, а не только во время звонка setup.

Если вы начинаете корпоративную оценку, страница обращения в отдел продаж — это правильная отправная точка. Вы также можете ознакомиться с posture безопасности Linkly на странице безопасности перед первым разговором.