| Panel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
ON THIS PAGE
|
...
All communication with BSN.cloud is mediated by Amazon Route 53.
DDoS Protection
General Disaster Recovery
Each BSN.cloud server has a backup server that can take over in case of unscheduled downtime. The database server for the BSN.cloud has both a mirror and a backup that frequently update to prevent data loss in event the production database goes offline.
Incidents are managed on a case-by-case basis. The recovery time objective (RTO) is 30 minutes or less, while the recovery point objective (All calls to BSN.cloud domains are directed through Route 53 access points and distributed across load functions to the proper nodes. Traffic is automatically guided to locations based on geographic location.
DDoS Protection
Route 53 protocols automatically scale and distribute load to avoid being overloaded in case of a distributed denial of service (DDoS) attack. Backups are readily available to take over in the event a server becomes overloaded.
General Disaster Recovery
Each BSN.cloud server has a backup server that can take over in case of unscheduled downtime. The database server for the BSN.cloud has both a mirror and a backup that frequently update to prevent data loss in event the production database goes offline.
Incidents are managed on a case-by-case basis. The recovery time objective (RTO) is 30 minutes or less, while the recovery point objective (RPO) is to prevent loss of any customer data. There are different thresholds for communicating impairments and outages to users, depending on whether the downtime is scheduled or unscheduled.
...
Every API call requires account authentication before affecting changes on the BSN.cloud servers or returning content from the database.
Operation Block Diagram
Notes
* During normal operations, the Remote Monitoring Server only receives updates from the Monitoring Server within Data Center 1. If the Remote Monitoring Server is no longer receiving updates from the Monitoring Server, it will switch to receiving information directly from each Gateway, Application, and Database node.
** The Database Servers in Data Center 2 constantly mirror the Database Servers in Data Center 1.
*** The Monitoring Server in Data Center 2 reports to the Monitoring Server in Data Center 1.
The network settings of a BrightSign player are highly flexible and configurable. As a result, the integrity of a player is the direct result of the publishing and network configuration specified during the player setup process. Some configurations are best for networks where security is of little importance, while other configurations give the player a significant amount of resilience to outside attacks.
...
All communication must be verified through OAuth2.0 servers before it may be passed between BrightAuthor:connected and a BrightSign Player.
BrightAuthor:connected Settings
The network settings of a BrightSign player are highly flexible and configurable. As a result, the integrity of a player is the direct result of the publishing and network configuration specified during the player setup process. Some configurations are best for networks where security is of little importance, while other configurations give the player a significant amount of resilience to outside attacks.
...
You can use the Web Inspector to debug webpages on the BrightSign Chromium instance (see the HTML Best Practices page for more details). This tool does not require authentication, so any party on the network can access and alter content on the BrightSign player; therefore, the Web Inspector should be disabled in production environments.
Linux Security
Though the BrightSign application runs on a Linux stack, it is unlikely that conventional Linux malware will be able to infect BrightSign players. A BrightSign player will only execute a firmware image that has been cryptographically signed by BrightSign. Also, during normal operation, the filesystem used on the player is read-only.
...