Розміщення даних описує, де дані зберігаються або обробляються. Швейцарський сервер не встановлює розташування резервних копій, систем підтримки, зовнішніх інтеграцій або кожної особи з доступом; оцінюйте ці компоненти окремо.
Відокремте розташування машини від шляху даних
Мітка країни на плані хостингу відповідає на вузьке питання: де розташована зазначена конфігурація. Ваш застосунок усе одно може надсилати інформацію в інше місце. Звітування про помилки, доставка електронної пошти, обробка платежів, позасайтові резервні копії та адміністративний доступ є частиною служби, навіть коли вони відсутні на діаграмі інфраструктури. Розглядайте швейцарське призначення як один запис у карті даних, а не як висновок про весь проєкт.
Почніть із назви інформації, яку ви обробляєте. Публічний сайт документації, клієнтський портал і приватний архів потребують різних засобів контролю. Розрізняйте опублікований вміст, персональну інформацію, секрети автентифікації та внутрішні операційні записи. Запишіть, чому існує кожна категорія та що сталося б, якби її розкрили, змінили або втратили. Це робить подальші рішення про розташування конкретними, а не покладається на загальну привабливість юрисдикції.
Створіть невеликий реєстр обробки
Прослідкуйте одну репрезентативну дію користувача від браузера до сховища. Зазначте, яка система отримує запит, що вона записує та які інші служби повідомляються. Повторіть вправу для створення облікового запису, відновлення пароля, завантажень і підтримки. Ви часто виявите вторинні копії в журналах, чергах електронної пошти та діагностичних експортах. Записуйте їх, поки архітектура ще достатньо проста, щоб її змінити.
Використовуйте реєстр із призначенням, місцем призначення, власником доступу та рішенням про збереження для кожного компонента. Вам не потрібен складний інструмент відповідності, щоб почати. Корисна властивість — те, що хтось може пояснити кожен рядок і оновити його після нової інтеграції. Діаграма без місць резервного копіювання або адміністративного доступу є неповною для рішення про розміщення.
| Компонент | Що встановити | Корисні докази |
|---|---|---|
| Основна база даних | Місце хостингу та дозволений доступ | Специфікація служби та політика доступу |
| Копія відновлення | Місце призначення, збереження та видалення | Конфігурація резервного копіювання та процедура відновлення |
| Експорт підтримки | Вміст і одержувачі | Відредагований зразок і політика підтримки |
| Зовнішня інтеграція | Надіслана інформація та умови обробки | Конфігурація інтеграції та документація провайдера |
Зрозумійте відповідальність, яка залишається на вас
Федеральний уповноважений Швейцарії з захисту даних та інформації пояснює, що передача обробки на аутсорсинг не знімає з контролера відповідальності за захист даних. Його рекомендації охоплюють вибір обробників, надання інструкцій і перевірку поводження з персональними даними. Це причина перевіряти як відносини зі службою, так і розташування стійки. Точні зобов'язання для вашої організації залежать від застосовної нормативної бази та залученої інформації.
Там, де інформація може розкриватися через кордони, використовуйте відповідні офіційні рекомендації та отримайте пораду для рішень, які потребують юридичної оцінки. Уникайте заяви, що назва країни автоматично робить застосунок відповідним вимогам. Запитайте, хто є обробниками та субобробниками, де відбувається обробка та які домовленості застосовуються. Зберігайте відповіді разом з операційною документацією проєкту, щоб рішення можна було переглянути пізніше.
Зменште інформацію, яка потребує рішення про розташування
Збирайте лише те, що служить визначеній меті. Розсилка не обов'язково потребує повної поштової адреси, а звіт про усунення несправностей рідко потребує всієї клієнтської бази даних. Видалення непотрібних полів зменшує вплив і спрощує збереження. Тримайте секрети поза діагностичними інструментами та розгляньте, чи агреговані вимірювання відповідають на операційне питання без відтворення окремих записів.
Шифрування може допомогти захистити окремі копії, але визначте, хто контролює ключі та де відбувається розшифрування. Застосунок, який має обробляти читабельні дані, не можна розглядати так, ніби ніхто ніколи не зможе отримати до них доступ. Так само псевдонімний ідентифікатор може все ще пов'язувати записи з часом. Опишіть впроваджений контроль точно, а не використовуйте значок шифрування як заміну карті обробки.
Практичний сценарій: невеликий клієнтський портал
Уявіть портал, розміщений на швейцарському VPS, з незалежною резервною копією для відновлення та стороннім сервісом електронної пошти. База даних клієнтів залишається на VPS під час звичайної роботи, але повідомлення для скидання пароля та сповіщення служби підтримки залишають цю машину. Команда має зафіксувати мінімальний набір полів у цих повідомленнях, призначення, яке використовується для резервних копій, і осіб, яким дозволено експортувати записи.
Розумний перегляд міг би замінити повний запис у звіті про помилку на випадковий ідентифікатор інциденту, скоротити термін зберігання діагностичних даних і обмежити доступ до резервних копій. Ці зміни корисні незалежно від обраної країни. Цей приклад є планувальною вправою, а не твердженням, що SwissOctet включає ці інтеграції або підтвердив конкретне розміщення даних.
Перевірте карту, перш ніж брати публічне зобов'язання
Перш ніж обіцяти користувачам певне розташування, порівняйте реєстр із фактичною конфігурацією та підтвердженими умовами обслуговування. Перевірте, чи процедури резервного копіювання та видалення працюють належним чином. Перегляньте експорти, агенти моніторингу та заплановані завдання, оскільки вони можуть створювати копії, про які ніхто не пам'ятає під час початкової покупки. Призначте відповідальну особу для затвердження нових призначень і оновлення реєстру, коли архітектура змінюється.
SwissOctet представляє швейцарські конфігурації у своєму каталозі. Умови обробки даних фактичним оператором, доступ служби підтримки та правила зберігання необхідно підтвердити окремо перед реальним замовленням. Обирайте інфраструктуру з урахуванням цієї межі: чітке швейцарське розташування може підтримувати вашу архітектуру, а повна та підтримувана карта даних підкріплює твердження, які ви про неї робите.
Ваш практичний контрольний список.
- Класифікуйте інформацію, яку обробляє проєкт.
- Складіть карту основного сховища, резервних копій, журналів та інтеграцій.
- Визначте обробників, власників доступу та рішення щодо зберігання.
- Перегляньте офіційні рекомендації щодо застосовних питань транскордонної передачі.
- Перевірте фактичну конфігурацію, перш ніж обіцяти розміщення даних.
Деталі, які мають значення.
Чи означає швейцарський сервер, що кожна копія залишається у Швейцарії?+
Ні. Призначення резервних копій, експорти, системи підтримки та інтеграції мають власні шляхи даних, і їх потрібно перевіряти окремо.
Чи усуває шифрування потребу в картуванні обробки?+
Ні. Вам усе одно потрібно знати, де існують дані та ключі, хто може їх розшифрувати і яка обробка відбувається.
Чи засвідчує цей посібник розгортання SwissOctet?+
Ні. Він надає метод планування. Умови обробки в реальному часі та впроваджені засоби контролю потрібно підтвердити для конкретної послуги.
Перейдіть до джерела.
Ці джерела підкріплюють технічні концепції в цьому посібнику. Дотримуйтеся поточної документації перед зміною робочої системи.
- FDPIC: Обробка даних у хмарі www.edoeb.admin.ch
- FDPIC: Передача обробки даних на зовнішній підряд www.edoeb.admin.ch
- FDPIC: Транскордонна передача персональних даних www.edoeb.admin.ch
Редакційне керівництво від SwissOctet. Приклади є ілюстративними. Специфікації послуг, доступні опції та договірні умови потрібно перевіряти окремо.