「Weblogic」を含む日記 RSS

はてなキーワード: Weblogicとは

2019-07-05

日立子会社SIer)を退職しました。

2019年6月を持ちまして、大学新卒入社後約7年勤務した会社退職しました。

良い機会なので記録に残したいと思います

スペック

地方国立大学工学部情報科卒。保有資格基本情報応用情報技術者

入社理由大手っぽかったため(何も考えてない)。

会社業務概要

日立製作所の子会社としてシステム開発運用保守、構築を担う会社

社員数は2~3000人。

入社してから運用、構築業務を行い、開発は未経験担当したシステムの分類は公共系のみ。

基本的には「客先常駐」で、システムが安定稼働に入った段階で別のプロジェクトに参画し、構築を行った。

身についたスキル

インフラ設計、構築

サーバ構築(オンプレミス業務としてOSMWの導入に携わることで、構築に必要知識を得られた。

ちょっと残念だったのが日立製品(JP1、uCosminexus Application Server)に携わる期間が長かったこと。

他社のAPサーバWeblogicJboss等)も触れ、インフラ屋さんとしての価値を高めたかった。

マネジメントスキル

力不足ではあったが5年目ごろから小さいチームのリーダになり、進捗管理顧客調整等を行った。

チームは3~5人でプロパー1人(私)、他は協力会社構成

協力会社メンバーは全員年上で、コミュニケーションにおいて苦労した部分もあったが、

人に恵まれ、大きな問題なくプロジェクト遂行できた。若いうちにリーダーを経験できたことはとても良かったと思う。

給与

最終年度で約560万。

◆内訳

 ・基本給 :26万

 ・扶養手当:2万(子ども二人)

 ・残業手当:8万(平均30時間/月)

 ・賞与  :約60万(年2回で業績により若干増減あり)

残業代は基本全額支給のため、それによって年収は大きく増減。

そのため、仕事がないのに残業するという所謂生活残業」をする人も少なからずいる。

また、最近働き方改革で定時退社を励行しているため、残業についてはかなり厳しくなっている。

昇給・昇格

昇給は若干ではあるが、たぶん毎年した。

昇格については、早い人で8年目から主任、15年目くらいで課長になる。

主任年収が600~800万(残業による)、課長年収が900~1000万。

主任まではある程度の実績とポイント資格等)があれば誰でもなれる(はず)。

ただ、課長以上になると「上が詰まっている」&「製作から下ってくる」ため、相当優秀でない限りはハードルが高いと思う。

劇的に仕事が増えて部&課が新しく作られれば話は別だが。

働き方

プロジェクトに合わせる形になるが、フレックスのため勤務体系が自由

上述の通り、残業についても働き方改革で定時退社を励行しており、男性の育休取得も推進している。

環境についてはシンクラ端末が一人一台支給され、インターネットがつながる場所であればどこでも仕事ができるという状態

どこでも仕事ができてしまうため、公私のバランスがとりずらいという方もいるかもしれないが、私にとっては最高でした。

これさえあれば在宅勤務も可能なので、娘が熱を出し保育園に行けないときは重宝した。

また、複数拠点サテライトオフィスがあり、社員証があれば使用できるため、打合せで移動が多い日はよく利用した。

働きやす環境作りにはかなり投資されているため、恵まれ環境仕事ができたと思う。

退職理由(順不同)

残業しないと給料低い。また、担当レベルだと成果を出した人とそうでない人で給与の差がほとんど付かない。

・新しい技術に関する感度が低い。

意識低い系がそこそこ多い。そしてその人たちは決して辞めない。優秀な若手はどんどん辞めていく。

SIerあるあるかもだが、協力会社に丸投げのプロジェクトがけっこうある。

・道半ばなのは重々承知なのだが飽きた。

SIer自体の将来性のなさ。

まとめ

転職先は事業会社IT企画部です。次が身の丈があった環境かどうか不安もありますが、新たな環境にワクワクしています

次の会社で働いてみて、前職の良し悪しもさらに見えてくると思うので、また気づきがあれば書きたいと思います

2015-11-12

参考訳:拡散したJavaシリアル化の脆弱性についてApache Commons声明

原文:https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread

原題Apache Commons statement to widespread Java object de-serialisation vulnerability

翻訳日:2015年11月12日(午後にタイトル日本語しました)

----

2015年11月1日 火曜日

Apache CommonsJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント

著者:Bernd Eckenfels(コミッター), Gary Gregory(Apache Commons副責任者)

AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクトシリアライゼーション(訳注:seriarization/シリアル化/直列化=ネットワークで送受信できるようにメモリ上のオブジェクトデータバイト列で吐き出すこと。シリアル化されたJava オブジェクトRMIなどのリモート通信プロトコル使用される。)を使用する際に任意Java関数の実行や操作されたバイトコードの挿入さえもを行う方法説明です。

Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereJBossJenkinsWebLogic、OpenNMSといった様々な製品調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオ記述しています

両者の調査活動は、開発者Javaオブジェクトシリアライゼーションに信頼を置きすぎていることを示しています認証前のシリアル化されていないオブジェクトにも。

Javaにおけるオブジェクトのデシリアライゼーション(訳注:de-serialization/非直列化=ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと)が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効オブジェクトツリーだけを保証しています

不幸にも、型のチェックが起こるまでの間に既にプラットホームコードが生成されて、重要ロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者コントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまます脆弱性のあるアプリケーションクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は(ローカルOSコマンドを実行するRuntime.exec()の呼び出しを含めて)機能を実行することができます

これに対する最も良い防御は、信頼されていないピア通信相手)とは複雑なシリアルプロトコルを使うことを避けることです。ホワイトリストアプローチ http://www.ibm.com/developerworks/library/se-lookahead/実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができますしかしながら、これは常にできることではなく、フレームワークアプリケーションサーバがエンドポイント提供しているような時にはできません。簡単な修正方法がなく、アプリケーションクライアントサーバプロトコルアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。

これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムSpringフレームワークApache Commons コレクションからクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン)を見つけています(訳注:provided)。これはこの脆弱性エクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日攻撃者が簡単に得られるチェーンです。

(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c

この脆弱性のために利用される(訳注:blamed)ことができない確かな機能実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的修正していくことが要求されますモグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。

Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能提供するかどうかです。

これには前例がありますOracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャー定義されているとデシリアライゼーションを拒否します。

これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできますApache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャー存在独立したこの機能無効化することを計画しています

しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンApache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。

このブログポストレビューのために Gabriel Lawrence に感謝したいと思います

Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラス提供する Java ライブラリです。InvokerTransformerコレクションにあるオブジェクトを(特にリフレクション呼び出しを通じてメソッドを呼び出すことで)変換するために使うことができる Transformer ファンクションインターフェース実装の一つです。

一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]

コメント

OracleWeblogicセキュリティアラートを発行しています

http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html?evite=WWSU12091612MPP001

提供されている回避策は、T3プロトコルへのアクセス(とリバースプロキシーにおけるT3メソッドフィルタリング)です。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん