You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 12, 2022. It is now read-only.
To maintain flexibility during our initial build out for the first sprint, we chose to set an IAM policy of *:*. This isn't the best choice security-wise but allowed us to work more quickly as a team.
Requirements
Remove *:* policies from IAM file
Create more specific and granular policies for needed services
Next Steps
Does this need to be a spike? If so -- we will need to generate a pointed follow-up ticket to capture the work needed and document.
Tech Notes
Assumptions
5. Consider the highest security standards as if receiving, sending and hosting Personal
Identifiable Information and Protected Health Information, even for this Challenge. All
system interfaces should be secured appropriately. Note: No PII or PHI shall be included
in the submission.
... AWS Installation Requirements
4. The Quoter shall provide an IAM policy file that can be applied to the EC2 instance for
running all install/test/uninstall scripts.
Patient Impact API Requirements
6. The API(s) need to be secure, and require authentication by the healthcare facility. For
the purposes of this challenge, the vendor may choose an appropriate
authentication/authorization solution for the problem. Please document the reason for the
choice in the Decisions section of the Case Study. Facility systems can only update
information for patients that relate to their facility (transferred into the facility,
transferred away from facility, or currently at a facility and patient status requires a
change).
As the solution stands right now, we know what policy updates we'd like to make now that we have our chosen services (but don't have time this sprint to implement). Our current IAM policy file will allow running install/test/uninstall scripts, and in our codebase we do implement authorization still.
So all that's left for future-us is to spend some time fine-tuning and tweaking the IAM file down.
The text was updated successfully, but these errors were encountered:
Description
To maintain flexibility during our initial build out for the first sprint, we chose to set an IAM policy of
*:*
. This isn't the best choice security-wise but allowed us to work more quickly as a team.Requirements
*:*
policies from IAM fileNext Steps
Does this need to be a spike? If so -- we will need to generate a pointed follow-up ticket to capture the work needed and document.
Tech Notes
As the solution stands right now, we know what policy updates we'd like to make now that we have our chosen services (but don't have time this sprint to implement). Our current IAM policy file will allow running install/test/uninstall scripts, and in our codebase we do implement authorization still.
So all that's left for future-us is to spend some time fine-tuning and tweaking the IAM file down.
The text was updated successfully, but these errors were encountered: