GX Technology : Chatbot - Security - Administrative Interface

Overview

The administrative interface is a new App Engine service to provide a simple user interface to modify the operational parameters of the Chatbot client and services (such as the v1 APIs). It will be hosted in the same Google Cloud Project as the existing chatbot services.

Team

Requirements

Minimal requirements are in place. Effectively all that is required is a modern web browser and a properly authorized account.

Source code Repository

https://github.wdig.com/GXTech/chatbot-server.git (specifically the chatbot-admin sub-module).

Google Cloud Platform

Overview

Google Cloud Platform Components Used

App Engine, CloudSQL, Cloud Storage, Pub Sub

Authentication

User authentication will be provided by MyID using OIDC Authorization Code Flow. MFA will be required as it is an external facing service. Sessions will terminate after 15 minutes of inactivity.

Authorization

Authorization will be determined via Keystone and enforced at the resource level. An all-or-nothing, role-based approach will be implemented for the initial release as the user interface will not be refined sufficiently to delegate administrative functionality.

Content

Static content will be bundled with the application. Content updates will require the service to be built and deployed.

APIs

No external/backing APIs will be used by this service

Google App Engine (GAE)

Monitoring

Only default monitoring will be in place. This is not a user-facing service so availability is not business-critical

Encryption

Settings will be encrypted at rest. Encryption keys are stored in Hashicorp Vault (https://prodkeys.disney.network/) and injected into the build artifact at time of deploy. Transport-layer security will be used for communication between user and server.

Google Pub/Sub

Subscribers

Subscribers will receive messages via pull delivery so that each active subscription will receive the messages. Currently, the only message sent will be a notification for subscribers (App Engine instances within the project, such as those serving the chatbot APIs) to reload the configuration from database. No details will be passed in the message.

API

We will be using Google's Java client library for Pub/Sub

Encryption

Sensitive data will not be sent via Pub/Sub. As such, encryption will not be used. 

Google Cloud Storage (GCS)

Buckets

We will be using the existing public GCS bucket to provide client configuration files.

Encryption

Encryption will not be used on the public GCS bucket as the files are meant to be usable by the chatbot client loader, and thus must be loadable by anonymous users.

Data

New files stored in the public bucket will be used by the chatbot client loader for per-product configuration. No sensitive data will be stored as it is expected to be public.

Client configuration data will include

• Chatbot
  • Enabled flag
  • Theme
  • Position
  • Docked status
  • Product identifier
  • State
  • Locales available
  • etc
• Zendesk integration details
  
  • Enabled fag
  • Chat Department
  • Tags to be added to tickets
  • Brand
  • Zendesk key expected by Zendesk Script
• Plugin configuration
  • OneID
    • Client ID
    • Responder Page
    • CSS override
    • etc
  • CTO
    • Site Code
    • Account
    • Brand Segment
    • etc

The above is a generalization. Full details for the configuration can be seen at https://github.wdig.com/GXTech/chat-client/blob/master/src/shared/props.js. The exact file format has yet to be determined.

Google CloudSQL

Encryption

Encryption-at-rest implemented in the same manner as it is with CloudSQL. Encryption settings will be stored in Hashicorp Vault (https://prodkeys.disney.network/) and injected into the build artifact at time of deploy.

The configuration can support multiple versions. This allows us to keep decrypting data encrypted with older versions while encrypting/decrypting with the new version. This allows us to re-encrypt existing data in the background without any impact to the service. We generally configure the encryption to be AES-256 for data at rest. A unique initialization vector is used each time data is encrypted.

Should we need to index encrypted data (which we do not with Phase 1), we will used the versioned hashing support provided by commons-crypto. This allows us to support multiple versions with configurable algorithm, start and end salts, and encoding. The hashes can be updated in the same manner as with the versioned encryption.

Data

Audit Logs

We will be performing audit logging of actions taken by users. We will need to store

• The user's Hub ID (encrypted)
• The user's IP Address (encrypted)
• The timestamp
• The action taken
• The previous value (encrypted)
• The new value (encrypted)

Configuration

We will be storing configuration data in the chatbot.config table. We will be storing

• The name
• The value (encrypted)

It is not anticipated that the configuration data will contain sensitive data. It is encrypted to future-proof the application in the event a future requirement arises and is approved.

Audit Logging

Audit logging will occur for all actions authenticated users perform. Failed authentication cannot be logged as this is handled by MyID alone. Logs will be retained indefinitely as there is no guest data logged. Audit logs can be accessed via a simple interface which will provide simple search functionality (date range, user ID, IP Address).

Application Logging

App Engine performs standard request logging. As such, sensitive data will only be transmitted in the request body and not as path or query parameters. In addition to standard request logging, warnings and errors will be logged with the associated request. Should the warning or error contain any sensitive data, it will be encrypted, scrubbed, or otherwise suppressed.

User Interface

The interface is standard server-generated pages served to a web browser. The interface will be used to view, add, and edit key/value pairs and view audit logs.

Threat Model

Existing system in grey.