Liferay図鑑は非公式の情報サイトです。Liferay, Inc.・日本ライフレイ株式会社とは関係ありません。

Liferay図鑑

カテゴリー: セキュリティ

  • Liferay Hungary、NIS2監査を自主的に完了と発表

    ニュースのポイント

    • Liferay Hungary Kft.は、NIS2監査を自主的に完了し、内部プロセスが指令とハンガリーの法的枠組みに適合していることが確認されたと発表した。
    • 確認された領域は、ガバナンスとリスク管理、インシデント管理、サプライチェーンのセキュリティ、事業継続の4つ。
    • NIS2はEU 2022/2555として定められたサイバーセキュリティ枠組みで、加盟国の国内法化期限は2024年10月17日だった。顧客・パートナーには委託先デューデリジェンスの負担軽減などの利点があるとしている。

    編集部コメント

    これはLiferay側の組織(Liferay Hungary Kft.)の監査に関する発表で、Liferay DXP製品自体の認証を示すものではありません。

    EU域内の顧客に提供する場合は、委託先評価の資料として参照できるか、自社の要件と照らして確認してください。

    出典：Liferay公式ブログ（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

  • Liferay PaaSでModSecurityの有用なログを出す設定の要点

    ニュースのポイント

    • ModSecurityはwebserver/LCP.jsonのLCP_WEBSERVER_MODSECURITYにOff・DetectionOnly・Onを指定して有効にする。まずDetectionOnlyで始め、チューニング後にOnへ移行することが推奨されている。独自のmodsecurity.confを置くと既定設定が置き換わるため、必要な設定をすべて含める必要がある。
    • コンテナは入れ替わり得るため、SecAuditLogは/dev/stdoutにしてLiferay Cloud Consoleへ流す。SecAuditEngineはRelevantOnlyにして警告・エラー等のみ記録し、SecAuditLogPartsからレスポンスボディを記録するEを外すとログ量を抑えられる（著者の事例）。
    • NginxのerrorログにModSecurityのMatchedメッセージが出るため、error_log /dev/stdout warnを設定する。Cloud Consoleのログ保持は30日で、長期保存にはlcp logコマンドで定期的にダウンロードする運用が紹介されている。

    編集部コメント

    記事の出発点となる設定例（SecAuditEngine RelevantOnly、SecAuditLogParts ABIJDFHZK、SecAuditLog /dev/stdout、SecDebugLogLevel 3など）が示されています。Eを外してもレスポンスボディの検査自体が止まるわけではない（SecResponseBodyAccessで制御）点は注意が必要です。

    WAFをいきなり有効化せず、まず検知のみで運用してログを確認する、という進め方はPaaS以外でも参考になります。

    出典：liferay.dev（David H Nebinger、2026年8月18日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

  • DXP 2026.Q1のOIDCバックチャネルログアウト対応の解説

    ニュースのポイント

    • 記事によると、Liferay DXP 2026.Q1はOpenID Connectのバックチャネルログアウトに対応している。LiferayはRelying Party（RP）としてのみ動作し、Keycloak、Microsoft Entra ID、Oktaなどの外部OpenID Providerに認証を委ねる。
    • OPがサーバー間通信で署名付きLogout Tokenを送り、Liferayは/o/open_id_connect/backchannel_logoutで検証して該当セッションを無効化する。通常どおりOIDCを設定し、このエンドポイントのURLをOPに登録する。署名検証に失敗した要求は拒否される。
    • RP起点のログアウト（LiferayからOPのSSOセッション終了を依頼する方式）は将来のリリースで計画されているが、ロードマップは変更され得ると記事は述べている。

    編集部コメント

    運用上は、OPからLiferayのエンドポイントへ到達できること（リバースプロキシ、ファイアウォール、DNS、TLSなど）が前提になります。ユーザーのブラウザ上では即時の変化はなく、次にポータルを操作した時点でログアウトが反映されるとのことです。

    登録手順はOPごとに異なります。詳細は原文をご確認ください。

    出典：liferay.dev（David H Nebinger、2026年8月5日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

  • セキュリティスキャナーが指摘するCVEは、Liferayの脆弱性とは限らない

    ニュースのポイント

    • 記事は、「ライブラリにCVEがある」「脆弱性が存在する」「Liferay DXP経由で悪用できる」の3つを別の問題として区別すべきだと説明しています。
    • Spring関連やLog4j 1関連のCVEを例に、悪用には特定の機能や条件が必要で、Liferayが使っていない機能に関するものは影響しない場合があると述べています。対応は「影響なし」「パッチや強化」「アップグレード」の3つに整理されます。
    • 顧客が独自のOSGiモジュールなどで脆弱な機能を有効にすると、新たな攻撃対象になる可能性があります。スキャナーの指摘を消すためにJARを独自に差し替えることは推奨されていません。

    編集部コメント

    監査やスキャナーの結果を受けたときは、件数だけで判断せず、Liferay側の公式な見解（影響の有無）を確認する流れが大切だとわかります。

    公式の脆弱性一覧は、当サイトの「公式リンク集」にまとめています。

    出典：liferay.dev（David H Nebinger氏、2026年8月16日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）