cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <blackn...@gmail.com>
Subject Re: Sensitive Logging
Date Wed, 19 Jul 2017 12:49:10 GMT
I'll look forward to seeing what is introduced.  Ultimately, there aren't
that many sensitive fields in an application and a pluggable module to
obscure those fields would likely be fine.


On Wed, Jul 19, 2017 at 8:41 AM, Andrus Adamchik <andrus@objectstyle.org>
wrote:

> Hi Mike,
>
> While I totally support solving this problem, I am not keen on overloading
> the core model with extra properties. We had this discussion under few
> different subjects, but it really comes down to the fact that there can be
> an infinite number of meanings one can associate with their model
> attributes (e.g. cayenne-crypto treats certain attributes as encrypted; a
> serialization framework may treat certain attributes as transient, etc.,
> etc.). We just can't support all these things in the core. So I suggest
> that we don't.
>
> Instead we may design this as an extension that can work on top of the
> core model. Kind of like cayenne-crypto, that determines which columns need
> to be encrypted not from the DataMap, but using a pluggable strategy
> (column naming convention by default).
>
> Also in 4.1 we will have a much more flexible model extension mechanism,
> which Nikita is about to present. All those requests that we had over the
> years of adding model comments and other arbitrary metadata will likely be
> fulfilled soon. So it will be easier to write extensions like the one you
> propose.
>
> Andrus
>
>
>
> > On Jul 19, 2017, at 3:28 PM, Michael Gentry <blacknext@gmail.com> wrote:
> >
> > Right now, everything is logged.  It would be useful to be able to
> > configure certain column values to not be logged, especially in a
> > production environment.  The main use case for this would be PII
> > (Personally Identifiable Information -- passwords, birthdays, social
> > security numbers, etc).  Arguably, that information should be
> > hashed/encrypted, but it is still not something you'd want leaked into a
> > log file.  Whenever a value isn't to be logged, put "[skipped]" in the
> log
> > output.
> >
> > I think it should work something like this:
> >
> > DataMap:
> >
> > Add a "Sensitive Logging" checkbox.  Perhaps right under the "Optimistic
> > Logging" checkbox.  Default = ON.
> >
> >
> > DbEntity / Entity Tab:
> >
> > Add a "Sensitive Logging" checkbox (basically mirroring the ObjEntity
> > "Optimistic Logging" checkbox).  Default = ON.
> >
> >
> > DbEntity / Attributes Tab:
> >
> > Add a "Sensitive Logging" checkbox column (beside PK and Mandatory).
> > Default = OFF.  (OFF means log the value normally.  ON means
> conditionally
> > log per behavior below).
> >
> >
> > Upgrading older models:
> >
> > Default DataMap and DbEntity to ON.  Leave DbEntity attributes OFF.
> >
> >
> > Behavior:
> >
> > skipped =
> >    DataMap.ON &&
> >    DbEntity.Entity.ON &&
> >    DbEntity.Entity.Attribute.ON &&
> >    Log.Level > DEBUG
> >
> > if skipped
> >    log [skipped]
> > else
> >    log value
> >
> >
> > In a production environment, log levels are typically
> > INFO/WARN/ERROR/FATAL, so factor that into the skipping equation. When
> > developing, log levels are typically DEBUG/TRACE, and in that case, log
> the
> > value.
> >
> > Also, given that all of the above can be changed at run-time, it allows
> > flexibility in a production environment to turn the sensitive logging
> > on/off through admin interfaces should the need arise.
> >
> > Thoughts?
> >
> > Thanks,
> >
> > mrg
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message