cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikita Timofeev <ntimof...@objectstyle.com>
Subject Re: Sensitive Logging
Date Wed, 19 Jul 2017 14:46:43 GMT
Hi Michael,

Yes I have some new code for extension mechanics in project's XML, it
can store and load arbitrary data along with model and do it in such
way that it can be totally disabled at runtime.
It's used as a proof of concept to store comments and reverse
engineering config.

But in your case it's really better to create new JdbcLogging
implementation that can skip some attributes defined by pluggable
strategy as suggested by Andrus.

On Wed, Jul 19, 2017 at 3:49 PM, Michael Gentry <blacknext@gmail.com> wrote:
> 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
>>
>>



-- 
Best regards,
Nikita Timofeev

Mime
View raw message