0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

i-FILTER×m-FILTER連携時の自動作成パーツについての注意点

Last updated at Posted at 2019-02-12

検証時のメモ

以下検証環境にて実施

■環境
 i-FILTER Ver.10.20R01-20181016
 m-FILTER Ver.5.11R01-20180802

i-FILTER×m-FILTER連携を有効化すると自動的に以下URLリストと識別名リストが作成される。

*m-FILTER連携URLリスト(完全一致)
*m-FILTER連携URLリスト(部分一致)
*m-FILTER連携デコードリスト(完全一致)
*m-FILTER連携デコードリスト(部分一致)

この4つのパーツだが、参照ロック及び編集ロックが解除されておりどの権限のユーザでも編集ができてしまう。

それを避けるために参照ロック及び編集ロックをするため、ルールパーツの*を外してパーツを保存してしまうとi-FILTER×m-FILTER連携が正常に動作しなくなる。

具体的にはパーツ名を変更してしまうとi-FILTER側はパーツがないため例外処理を返す。
その例外処理が返ってきた場合、m-FILTER側は未カテゴリ扱いをする結果、偽装メール対策機能側で偽装レベル3と強制的に判定される。
つまり偽装メール対策機能をデフォルトで運用している場合、URLがメールのどこかしらに記載がされた場合、そのメールすべてが隔離されてしまう。

困ったことにパーツの編集権限を持ったユーザが誤って変更すると恐ろしいことにURLが記載されたメールがすべてメールが隔離されメール不通状態となる。

マルチテナント的にグループ単位で権限を委譲している環境だと触らないように運用徹底が必要である。

もし変更してしまったことを能動的に知りたい場合はm-FILTERの「i-filter.log」ログから「-19」※の値をひっかけてログ監視をする必要があります。
※「-19」はURLリストがなかった場合のエラーコード

私は最初から触れないようにロックするか、そもそも変更できないようにすべきではないかと思います。(ロックだと全体管理者で設定変更できちゃいますし)
ユーザーってなんでかわからないけど普通ならやらないような設定を平気でやったりする方もいるので...

以上、検証結果でした。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?