Auditing at block level

hi,

Currently we have audit collector set to true. So wanted to check if it is possible to control ROR audit at block level rather than at overall level? For example, I might have a block to allow access to system id for which I dont want to audit. But I might have another block to allow access to users to some sensitive data. So I would want to audit all access to this index. Is it possible to do this kind of auditing today in ROR?

Also, previously there was some discussion about being able to capture the actual query run the user as part of the audit information. Was that feature implemented or planned to be implemented?

Thanks!

Hi @askids,

  1. Please see the verbosity rule that you can add to any ACL block if you don’t want certain requests to be logged.
  2. Yes you can use the alternative audit log serializer QueryAuditLogSerializer if you want to log the HTTP body if the requests.

This is great @sscarduzio. Can you let me know, which version of ROR has this QueryAuditLogSerializer feature? We are currently using 1.16.20. So trying to determine, if any upgrade is needed.

@askids the QUeryAuditLogSerializer was added in 1.16.20, lucky you :slight_smile:
However I recommend upgrading anyway when you can because of the security fixes we had in these last 8 releases.

Lucky me :grin: Will plan to upgrade in early Dec.

Couple of other queries. When I log the content, will it capture it, only for search request or will it capture other actions also like indexing/update etc.

Also, there was one feature that was discussed some time back about writing audit to remote cluster. Is there anything planned on that front?

You can view a sort of changelog summary in the download page.

QueryAuditLogSerializer is quite dumb, so it will just log whatever you throw at it. You need to use the ACL wisely with the verbosity rule, or alternatively create a custom audit log serializer with an extra if that checks on the action string. I.e.

/*
 *    This file is part of ReadonlyREST.
 *
 *    ReadonlyREST is free software: you can redistribute it and/or modify
 *    it under the terms of the GNU General Public License as published by
 *    the Free Software Foundation, either version 3 of the License, or
 *    (at your option) any later version.
 *
 *    ReadonlyREST is distributed in the hope that it will be useful,
 *    but WITHOUT ANY WARRANTY; without even the implied warranty of
 *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *    GNU General Public License for more details.
 *
 *    You should have received a copy of the GNU General Public License
 *    along with ReadonlyREST.  If not, see http://www.gnu.org/licenses/
 */
package tech.beshu.ror.requestcontext;

import tech.beshu.ror.commons.ResponseContext;

import java.util.ArrayList;
import java.util.List;
import java.util.Map;

public class SmarterQueryAuditLogSerializer extends DefaultAuditLogSerializer {

  private static final  List<String> ALLOWED_STRINGS = new ArrayList<String>(){{
    add("action1");
    add("action2");
  }};

  @Override
  public Map<String, ?> createLoggableEntry(ResponseContext rc) {
    Map<String, Object> map = (Map<String, Object>)super.createLoggableEntry(rc);
    String action = rc.getRequestContext().getAction();

    if(ALLOWED_STRINGS.contains(action)) {
      map.put("content", rc.getRequestContext().getContent());
    }
    return map;
  }
}

About the audit log shipping to append-only external cluster: we are working on tackling this and other audit challenges in a cohesive, and well rounded way. So yes, it’s in the roadmap.

“You need to use the ACL wisely with the verbosity rule” - lets say for same id, i create 2 blocks. One for index read access with verbosity as info and one for write access with verbosity as error. Will it create a conflict or will both read and write work as before?

Great. It may be worthwhile to consider adding support to allow writing to different target indexes from different ROR blocks along with timeseries naming support that you added on the default audit index, sometime back.

There is no conflict in a sequentially evaluated ACL, first matched block counts. You can intercept the reads first (using carefully the actions rule) with verbosity info. The writes will not match, and continue evaluation to the following block (with no actions rule specified) which has verbosity: error.

Yeah this looks like the appender/logger logic being used by log4j, can be part of the advanced logger module.

@sscarduzio thanks for confirming. Also, currently, when we enable ROR auditing, it also writes the same entry to Elasticsearch log file as well. Is there a way to just write the entries only to index and not write to ES log file? Currently, this causes the ES log file to fill up with all success requests, which though we want to audit, but not on the ES log itself. So having an option, where we only write to index and not to ES log will greatly help for such auditing requests.

No for now you can only tweak the log entries away via log4j config file (not sure how, but should be possible and I’m quite sure somebody did it)