Проверено · Ресурсы Hosmio
Перед началом
Подготовьте базовый эскиз архитектуры, ответственных за приложение и резервные копии, а также любые клиентские ограничения. Используйте категории и синтетические примеры. Не вносите в рабочую таблицу фактические записи клиентов, пароли, токены доступа или неотредактированные журналы.
01
Проследите одну полную пользовательскую задачу.
Выберите типичную задачу, например загрузку проектного документа в клиентский портал. Проследите, куда идёт запрос, где хранятся его метаданные, где оказывается файл и что происходит после загрузки. Включите миниатюры, обработку в очереди, исходящие уведомления и отчёты об ошибках, если они существуют. Цель — описать вашу реализацию, а не заполнить все возможные категории.
Затем проследите вторую задачу, которая читает или экспортирует данные. Экспорт часто выявляет копии, отсутствующие на схеме инфраструктуры: скачанный оператором архив, интеграцию отчётности или файл, приложенный к запросу в поддержку. Спросите, кто контролирует каждое место назначения и зачем оно нужно.
02
Отделите постоянные копии от доступа.
| Запись | Назначение / ответственная роль | Всё ещё необходимые доказательства |
|---|---|---|
| База данных приложения | Метаданные проекта / оператор приложения | Фактическая страна хостинга и правило хранения |
| Загруженные документы | Клиентские файлы / владелец контента | Место хранения и процесс удаления |
| Копия восстановления | Восстановление сервиса / оператор восстановления | Расположение резервной копии, доступ и результат восстановления |
| Отчётность об ошибках | Расследование сбоев / владелец инцидента | Экспортируемые поля и принимающая организация |
| Административная сессия | Поддержка приложения / авторизованный оператор | Схема доступа и процесс аудита |
Строка о доступе полезна, даже если она не создаёт намеренно сохраняемую копию. Зафиксируйте участвующие организацию и процесс, что человек может видеть и возможен ли экспорт. Не делайте из этой строки универсального правового вывода. Критерии передачи EDPB зависят от фактических организаций и контекста обработки. EDPB: международные передачи данных ↗
03
Помечайте качество каждого ответа.
Используйте небольшой набор состояний: задокументировано, заявлено, но не проверено, неизвестно и неприменимо с указанием причины. Привяжите источник и дату пересмотра к ответу, а не только к странице, содержащей таблицу. Схема, составленная вашей командой, и договор, предоставленный провайдером, отвечают на разные виды вопросов.
Например, ваш код может подтвердить, что отчёт об ошибке не содержит содержимого документа, тогда как только поставщик отчётности может указать, где работает его процесс хранения или поддержки. Держите эти доказательства раздельно. Когда они противоречат друг другу, задайте конкретный вопрос и сохраняйте нерешённое состояние, пока конфликт не будет урегулирован.
04
Назначьте каждой копии владельца и условие завершения.
Для каждой постоянной копии зафиксируйте, зачем она существует, как долго проект нуждается в ней, кто контролирует удаление и что происходит при завершении сервиса. Копия восстановления может быть необходимой и всё же требовать определённого процесса хранения. «Есть резервная копия» — не полный ответ на вопрос, можно ли удалить старые данные или как долго они остаются восстановимыми.
Проверяйте и рутинные экспорты. Если оператор скачивает архив для расследования проблемы, команда должна знать, где он хранится и когда удаляется. Ссылайтесь на защищённые доказательства, а не встраивайте архив в карту. Сама запись должна оставаться полезной, не раскрывая описываемые ею данные.
05
Устраните неполную карту портала.
В иллюстративном обзоре оператор приложения может объяснить продакшен-хранение и запланированные экспорты, но место назначения резервных копий указано просто как «провайдерская резервная копия». Оператор восстановления запрашивает охват места назначения, правила доступа и фактическую процедуру восстановления. Пока они не предоставлены, строка остаётся неизвестной, а решение о стране — условным.
Тем временем обнаруживается, что интеграция отчётности об ошибках включает полные URL запросов. Команда проверяет, могут ли эти URL нести идентификаторы проекта, обновляет инвентаризацию полей и просит контактное лицо клиента оценить изменённый поток данных. Из этого примера не делается никакого вывода о стране или соответствии; он показывает, как карта может выявить конкретный нерешённый вопрос.
06
Проверьте полноту и поддерживайте карту.
Попросите оператора резервных копий и сопровождающего приложение независимо пройти через восстановление и расследование инцидента. Спросите, откуда каждый шаг получает данные и кто может к ним получить доступ. Если любой процесс использует место назначения, отсутствующее в рабочей таблице, добавьте его и назначьте владельца для оставшихся фактов.
Пригодная к использованию карта заканчивается кратким списком открытых пунктов, каждый из которых привязан к ответственной роли и решению, на которое он влияет. Пересматривайте его после добавления интеграций, изменения политики резервного копирования, предоставления нового административного маршрута или перемещения регионов. Используйте матрицы решений по хостингу для оценки полученных фактов и руководство по утверждению изменений при изменении схемы.
Эта рабочая таблица систематизирует операционные доказательства для консультантов проекта. Она не устанавливает применимое право, не санкционирует передачу и не подтверждает резидентность данных. Выбранная страна сервера не устанавливает местоположение резервных копий, экспортированных данных или административного доступа.