API key security - Githubissues

Description

Stronger language when an API key is created that it cannot be shared anywhere publicly. More details in the API documentation, linked from the Terms of Use, on how to keep API keys secure.

As a developer and Notify API user, I need information documented in obvious places so that I understand how to keep my API keys secure and so I can follow the Terms of Use for GC Notify.

WHY are we building? For better API key security and so our users are able to follow our Terms of Use so we don't have security issues. WHAT are we building? Updated documentation in the UI and in the API documentation VALUE created by our solution Better comprehension from developers of how to keep their API keys safe and fewer security issues or incidents related to API keys

Documentation and Artifacts

From UK Notify's new Terms of Use: NotifyUK has some new terms of use, including nice stuff around api keys API keys If you use the Notify API to send messages, you must protect your API keys from unauthorised access or disclosure. This includes encrypting the keys at rest and in transit. You should also rotate your keys: at least once every year when someone with access to a key leaves your team whenever you suspect that a key may have been compromised Do not hard-code your API keys. We recommend that you use a cloud service provider’s key management service to keep your API keys secure. For more information, read the NCSC guidance.

Acceptance Criteria

Given a developer is using the GC Notify API, when they read the Terms of Use and the API documentation while onboarding, then they understand the steps to keep their API keys safe

Given a developer is creating an API key in GC Notify, then when they take that step, they are presented in the UI with further details reminding them how to keep their API keys secure.

[ ] Cypress UI tests if needed.
[ ] Generate appropriate log messages so that executions of this feature can be tracked
[ ] Can misuse of this feature cause harm? If yes, create an alert
[ ] Update the status of related findings, insights, and hypotheses on the Research Airtable
[ ] Once change/fix/feature is implemented, link relevant Airtable records to design artifacts (Figma)
A11y
Bilingualism
Privacy considerations
Security controls in place
Measuring success and metrics

Related Research Airtable records

UK Notify updated their Terms of Use and we have some information from past support tickets/issues

QA Steps

[ ] Tested in a realistic production scenario

GC Articles Publish checklist

[ ] Supporting feature is released and unflagged
[ ] Create or update slug
[ ] Page content and slug is translated
[ ] Document links to and from the page
[ ] Add page slug and title to inventory
[ ] If new page, add WAF rule
[ ] Create new page or update existing page content
[ ] Create or update translation to the page
[ ] Link translations by choosing an assigned translation
[ ] If new page, save as draft
[ ] If existing page, update the page
[ ] Post page in Slack for last minute reviews
[ ] On staging: Clear the cache through GC Notify's admin panel
[ ] On staging: Check links, images and language toggle
[ ] Give a heads up to the app-team channel once ready to publish
[ ] On staging and production: Clear the cache through GC Notify's admin panel
[ ] Clear Cloudfront cache in GCA as needed (Andrew and Phil are GCA admins)

cds-snc / notification-planning