|
1. Архитектура и разделение данных |
Службы, работающие и предлагаемые в облаке, должны находиться в архитектуре с множеством сторон, в которой доступ к данным клиента можно просматривать только на основании авторизации, назначенной компанией. Он обеспечивает эффективное разделение логических данных через уникальную идентификацию Employee Identification, которая позволяет получить доступ к информации, основанной на привилегиях ролей. Сегрегация данных должна выполняться путем предоставления отдельных сред для различных функций, то есть для тестирования и производства.
Это возвращает заказчику энергию, гарантируя, что данные обрабатываются только по указанию заказчика, по всей цепочке обработки и соблюдению принятых мер должны подвергаться аудиту.
Как минимум на ежегодной основе все предлагаемые услуги должны пройти оценки безопасности внутренним персоналом, который включает оценки уязвимости инфраструктуры и оценки безопасности приложений.
Все системы, используемые для передачи предлагаемых услуг, включая операционные системы, информацию журнала в их соответствующий системный журнал приложений или централизованный сервер syslog (для сетевых систем), будут храниться для того, чтобы обеспечить проверку и анализ безопасности, а журналы систем и приложений будут храниться в течение минимального периода в шестьдесят (60) дней.
Предлагаемые Услуги, предоставляемые через Internet Browser или Mobile App, должны иметь различные функции безопасности, которые можно настроить. Эти элементы управления включают, но не ограничиваются следующими: |
|
• |
Идентификаторы пользователей как уникальные идентификаторы пользователей, чтобы убедиться, что действия могут быть прослежены до человека. |
• |
Использование элементов управления reCaptcha для вызова доступа после нескольких последовательных неудачных попыток входа в систему. |
• |
Прекратить сеанс пользователя после периода бездействия. |
• |
Чтобы контролировать длину пароля. |
• |
Для соответствия требованиям сложности пароля. |
|
6. Политики безопасности и процедуры |
Предлагаемые услуги должны работать в соответствии со следующими политиками и процедурами для повышения безопасности: |
|
• |
Пользовательские пароли сохраняются с использованием солевого хеш-формата и не передаются в незашифрованном виде. |
• |
Будут сохранены записи журнала пользовательского доступа, содержащие дату, время, URL-адрес или идентификатор сущности, выполненную операцию (просмотр, редактирование и т. Д.) И IP-адрес источника. Обратите внимание, что исходный IP-адрес может быть недоступен, если NAT (трансляция сетевых адресов) или PAT (Port Address Translation) используется клиентом или его провайдером. |
• |
Журналы будут храниться в безопасном централизованном хосте для предотвращения несанкционированного доступа. |
• |
Пароли не регистрируются. |
Предоставляемые услуги должны контролироваться для несанкционированных вторжений с использованием сетевых механизмов обнаружения вторжений разработчиком или третьей стороной, назначенной для этой задачи. Данные, собираемые браузерами пользователей (например, тип устройства, разрешение экрана, часовой пояс, версия операционной системы, тип и версия браузера, системные шрифты, установленные плагины для браузера, активированные типы MIME и т. Д.), Могут быть проанализированы для безопасности, чтобы предотвратить мошеннические проверки подлинности, и обеспечить надлежащее функционирование предлагаемых служб.
|
8. Управление инцидентами |
Поставщик должен поддерживать политики и процедуры управления инцидентами безопасности и уведомлять влияющих клиентов без неоправданной задержки любого несанкционированного раскрытия их соответствующих данных Клиента Разработчиком или его агентами, о которых Разработчик узнает в объеме, разрешенном законом.
|
9. Аутентификация пользователя |
Весь доступ к предлагаемым услугам через Интернет-браузер, мобильное приложение или через API требует комбинации действительного идентификатора пользователя и пароля, которые шифруются через HTTPS во время передачи. После успешной аутентификации создается случайный идентификатор сеанса и сохраняется в браузере пользователя для сохранения и отслеживания состояния сеанса.
|
10. Физическая безопасность |
Если производственные центры обработки данных, используемые для предоставления покрываемых услуг, обрабатываются внешними службами, получите информацию о его состоянии безопасности, например: AWS Security Whitepaper.pdf
|
11. Надежность и резервное копирование |
Все сетевые компоненты, балансировщики нагрузки, веб-серверы и серверы приложений настроены в избыточной конфигурации. Все данные клиента, переданные в покрываемые Услуги, хранятся на основном сервере базы данных с автоматическим резервным копированием с использованием функций восстановления по времени. Все резервные копии Daily AMI будут сохраняться как минимум на 2 дня, а еженедельная резервная копия AMI будет сохранена как минимум на один месяц.
|
12. Аварийное восстановление |
Производственные системы предлагаемых услуг должны быть защищены многоуровневым планом аварийного восстановления, который предусматривает резервное копирование важных данных и услуг. Существует всеобъемлющая система процессов восстановления, позволяющая оперативно-критически важным системам вернуться в оперативный режим в течение максимально короткого периода времени. Процессы восстановления для базы данных, безопасности, системного администрирования, конфигурации и данных сети обеспечивают дорожную карту для персонала, чтобы сделать процессы доступными после сбоя службы.
Предлагаемые службы не будут проверять наличие вирусов, которые могут быть включены в приложения или другие данные, загруженные клиентами в предлагаемые услуги. Загруженные вложения не выполняются в предлагаемых услугах и, следовательно, не будут наносить ущерб или компрометировать предоставляемые онлайн-услуги в силу содержания вируса.
Предлагаемые службы должны использовать принятые в отрасли продукты шифрования для защиты данных клиента и связи во время передач между клиентской сетью и охватываемыми службами, включая 128-битные сертификаты TLS и 2048-разрядные открытые ключи RSA как минимум.
|
15. Возврат данных клиента |
Данные клиента, представленные в предлагаемые услуги, должны быть возвращены Заказчику по запросу.
|
16. Удаление данных клиента |
После прекращения предлагаемых Услуг клиенты могут запросить удаление данных Клиента, представленных в предлагаемые услуги, и этот процесс подлежит применимым правовым требованиям. Данные клиента, хранящиеся в инфраструктуре для предлагаемых услуг, будут удалены соответствующим образом.
|
17. Чувствительные данные |
Важно: следующие типы конфиденциальных персональных данных не могут быть отправлены в OfferedServices: финансовая информация (например, номера кредитных или дебетовых карт, любые связанные коды безопасности или пароли и номера банковских счетов); информация, касающаяся физического или психического здоровья человека; и информацию, связанную с предоставлением или оплатой медицинского обслуживания. Для ясности вышеуказанные ограничения не распространяются на финансовую информацию, предоставляемую разработчику, для проверки финансовых квалификаций и сбора платежей от своих клиентов.
Разработчик может отслеживать и анализировать использование предлагаемых служб для обеспечения безопасности и помогать разработчику улучшать как предлагаемые услуги, так и опыт пользователей в использовании предлагаемых услуг. Разработчик может делиться анонимными данными об использовании с поставщиками услуг с целью помочь разработчику в таком отслеживании, анализе и улучшениях. Кроме того, разработчик может совместно использовать такие анонимные данные об использовании на основе совокупности в ходе обычной работы нашего бизнеса; например, мы можем публиковать информацию публично, чтобы показать тенденции об общем использовании наших услуг.
|
19. Интеграция или взаимодействие с другими службами |
Предоставляемые разработчиком услуги могут интегрировать или взаимодействовать с другими услугами, предоставляемыми разработчиком или третьими лицами. Разработчик также может предоставить на многих платформах и функциях, которые позволяют пользователям узнавать о продуктах, участвовать в сообществах, подключать сторонние приложения и участвовать в пилотных проектах, тестировании и оценках, которые не входят в объем этой документации. Общение с пользователями, которые участвуют в таких платформах и функциях, таким образом, чтобы они соответствовали Закону о конфиденциальности. Кроме того, разработчик может связаться с пользователями для предоставления транзакционной информации о предлагаемых Услугах; например, через Диспетчер учетных записей или через созданные системой сообщения электронной почты. Разработчик должен предлагать клиентам и пользователям возможность деактивировать или отказаться от получения таких сообщений. Будучи разработчиком систем на основе облачных вычислений, TimeTec выполнил вышеуказанные требования с ключевой целью, чтобы поддерживать доверие клиентов. Документация по безопасности, конфиденциальности и архитектуре для служб, предоставляемых TimeTec, доступна на веб-сайте TimeTec Cloud.