[Baypiggies] The Django admin and SOX compliance

[Karla Reyes]

jj,

I am actually trying to solve that same problem, but in regards to access
to production hosted in aws / cloud.  And the way i am framing this problem
is, since sox does not cover any of the modern devops tools, our sox
auditors follow 10 DevSecOps guiding principles, the one related to this
would be [to have] :

*Least privilege access to the tools* - if you are being 'controlled' you
can't have elevated access.

So i just share my example, as it might provide you some insight into how
to solve your case.

For AWS, I am trying to define a role within the prod account (and another
non-prod account to steer sandbox & test usage to that), and assign this to
a CI automated user, forcing that way all changes through your CI pipeline
or automated deployment (happy path). Leaving a log/trace of this change.
So CI user gets read+ write access. but the rest of the team have read-only
role for troubleshooting purposes (non-happy path), which they will
still have to push through a script from your automated build process
(jenkins in our case).

What Deirdre mentioned of version controlling the record for changes, is
similar to turning on cloudtrail in aws, which we did. Except it only lets
you know who preferred the 'cowboy' approach, without enforcing* 'least
privilege access' *and comply with sox.

-Karla

On Wed, Dec 9, 2020 at 4:10 PM Deirdre Saoirse Moen <deirdre at deirdre.net>
wrote:

>
> On Wed, Dec 9, 2020, at 3:02 PM, Shannon -jj Behrens wrote:
>
> If you think about being compliant with certain things like SOX, SOC2, ISO
> 27001/2, one of the things you have to do is get a lot more careful about
> who can view and modify data. Consider the idea where you have a Django
> admin which allows you to mutate a bunch of the data in your database. Now,
> imagine a bunch of customer support agents making use of this Django admin
> in order to make changes on an as-needed basis.
>
> Now, imagine you want to add some workflow on top of this. Let's say a
> support agent needs to change some row (model object). However, we want
> such changes to be approved before making the change.
>
>
> In rails projects, I've just previously added a version (and tracking info
> like date and who made the change) to the data, and then incremented the
> version number when saving the record, with the unique key being the
> original UUID + the version. I haven't tried this in Django.
>
> There's also the wrinkle of documenting schema changes, because it's
> possible to lose data that way when it's transformed. In Rails, there was
> the acts_as_versioned gem, now succeeded by paper_trail, to handle that
> case. (This was above and in addition to migrations.)
>
> Once you've got it out of the database, looks like pyrsistent may help. In
> any case, I'm contributing to a project that uses it.
>
> Deirdre
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> https://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/baypiggies/attachments/20201209/6bbfd208/attachment-0001.html>